Gdy używasz ext4, możesz sprawdzić, czy nie ma uszkodzonych bloków za pomocą polecenia e2fsck -c /dev/sda1 # or whatever. Spowoduje to „czarną listę” bloków poprzez dodanie ich do złego bloku i-węzłów.
Co to jest równoważne z woluminem fizycznym LVM2? System plików na nim to ext4, ale prawdopodobnie wykryte uszkodzone bloki staną się nieprawidłowe, ponieważ bazowa konfiguracja LVM przenosi dane na dysku fizycznym.
Innymi słowy, jak mogę sprawdzić złe bloki, których nie można użyć w LVM?
Odpowiedzi:
Kiedy używasz ext4, możesz sprawdzić, czy nie ma uszkodzonych bloków za pomocą polecenia
e2fsck -c /dev/sda1lub cokolwiek innego. Spowoduje to „czarną listę” bloków poprzez dodanie ich do złego bloku i-węzłów.
e2fsck -cdziała badblocksna podstawowym dysku twardym. Możesz użyć badblockspolecenia bezpośrednio na woluminie fizycznym LVM (zakładając, że PV jest w rzeczywistości dyskiem twardym, a nie jakimś innym rodzajem urządzenia wirtualnego, takim jak urządzenie RAID z oprogramowaniem MD), tak jak używałbyś tego polecenia na dysku twardym który zawiera system plików ext.
To nie doda żadnych złych informacji o blokach do systemu plików, ale tak naprawdę nie sądzę, że jest to przydatna funkcja systemu plików; dysk twardy ma obsługiwać złe bloki.
Nawet lepiej niż badblocksuruchomienie autotestu SMART na dysku (zamień /dev/sdXna nazwę urządzenia na dysku twardym):
smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less
Sam test zajmie kilka godzin (dokładnie powie ci, jak długo). Kiedy to zrobisz, możesz zapytać o wynik smartctl -a, poszukaj dziennika autotestu. Jeśli wyświetli się komunikat „Zakończono pomyślnie”, twój dysk twardy jest w porządku.
Innymi słowy, jak mogę sprawdzić złe bloki, których nie można użyć w LVM?
Jak powiedziałem, sam dysk twardy zapewni, że nie użyje uszkodzonych bloków, a także przeniesie dane z tych bloków; to nie jest coś, co musi zrobić system plików lub LV. Z drugiej strony, gdy twój dysk twardy ma więcej niż kilka uszkodzonych bloków, nie chcesz czegoś, co je przenosi, ale chcesz wymienić cały dysk twardy, ponieważ jest uszkodzony.
dd. Częściej niż mogłoby się wydawać, nośnik jest w porządku, a dane zostały po prostu uszkodzone, więc zapisywanie go działa dobrze bez potrzeby ponownego mapowania.
dd” - ale prawdopodobnie nie powinieneś. Jeśli masz mdnalot, może zająć się tym problemem . @derobert prawdopodobnie będzie wiedział, co zrobić, gdy dysk nie jest częścią mdnalotu :)
Jestem prawie pewien, że LVM nie obsługuje złych bloków; oczekuje, że podstawowa pamięć do. I większość, jeśli nie wszystkie, to współczesne dyski twarde. Może być konieczne wykonanie zapisu do sektora, ale dysk powinien go odwzorować. (Może być konieczne, aby najpierw wykonać skanowanie powierzchni offline, np smartctl /dev/sda -t offline.).
To powiedziawszy, LVM nie przenosi danych, chyba że o to poprosisz, np pvmove. Możesz więc użyć funkcji ext4 badblocks; po prostu musisz ponownie sprawdzić, czy nie działają uszkodzone bloki pvmove. Żadna wspólna operacja (taka jak lvextend) nie przenosi danych.
Rozszerz nie przenosi danych, ponieważ LVM prowadzi mapę z informacją, że „zakresy logiczne 0–99 to zakresy fizyczne 200–299”, a następnie, gdy je rozszerzasz, dodaje tylko „zakresy logiczne 100–199 to zakresy fizyczne 100–199”. Lub nawet „zakresy logiczne 100–149 to zakresy fizyczne 50–99; zakresy logiczne 150–199 to zakresy fizyczne 140–189”. LVM nie przejmuje się tym, że zakresy fizyczne nie są uporządkowane lub nie są ciągłe.
pvckmoże sprawdzić metadane LVM, po czym spójność jest zadaniem systemu plików. LVM dotyczy tylko zarządzania woluminami, więc nie trzeba się przejmować, czy przestrzeń stanowiąca określony zakres jest zła, ponieważ oprogramowanie wyższego poziomu wychwytuje te problemy. W każdym razie metadane LVM zajmują tylko pierwszy (opcjonalnie także ostatni sektor) wolumin fizyczny.
Jeśli tylko pierwszy i ostatni sektor stosunkowo dużego fotowoltaiki (taki, jaki zobaczysz w produkcji) zdarzy się jednocześnie awarii, będziesz miał największe szczęście na świecie, ponieważ jest to tak mało prawdopodobne z astronomii. W przeciwnym razie, jeśli administrator wie, że wiele sektorów dysku uległo awarii, większość ludzi jest w porządku, po prostu zapisując takie rzeczy, jak to w polu „Dysk twardy zawiódł się na stałe i należy go wymienić”.
Jeśli pvckzwróci błąd, możesz sprawdzić, czy /etc/lvmgdzieś nie utworzono kopii zapasowej metadanych LVM . Jeśli tak, możesz pvcreatepodać kopię zapasową--restorefile
Składnia:
pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>
Przykład:
pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2
Jeśli przywracanie nie działa (na przykład, jeśli pierwszy sektor jest zły), możesz ponownie wykonać powyższe czynności, ale ustaw --metadatacopies 2(lub po prostu przejdź od razu do tego), który spróbuje zapisać metadane do pierwszego i ostatnie sektory w teledysku. Kiedy pvscanuruchomi się, sprawdzi oba miejsca i jeśli znajdzie metadane, zweryfikuje je na podstawie sumy kontrolnej. Jeśli suma kontrolna nie powiedzie się w pierwszym sektorze, ale zakończy się sukcesem w ostatnim sektorze, pojawi się komunikat o błędzie nie krytyczny.
Niby ręczne i uciążliwe, ale z drugiej strony jest to jeden z powodów, dla których ludzie są podekscytowani otrzymaniem redux zarządzania woluminami z BTRFS. W większości przypadków nie jest to aż tak duży problem z powodów wymienionych przez deroberta, a ponieważ ludzie, którzy absolutnie pozytywnie potrzebują ciągłości danych, zwykle korzystają z RAID i mają strategię tworzenia kopii zapasowych.
-crobi, zanim zadzwonisz do czegoś kompletnego bzdury.