Tutoriel Linux

Fsck w systemie Linux: naprawa odmontowanego systemu plików

Débutant5 min de lecture
À retenirLinux n'est pas réservé aux experts. Le bon point de départ : une distribution accessible, une sauvegarde propre et quelques commandes comprises.

Serwer restartuje się w trybie awaryjnym, partycja nie chce się zamontować lub jądro zgłasza błędy ext4. Pokusa natychmiastowego uruchomienia jest ogromna. fsck na pierwszym znalezionym urządzeniu. Właśnie tego należy unikać: naprawa na niewłaściwym woluminie lub na systemie plików, który jest nadal zamontowany, może pogorszyć szkody.

fsck to program uruchamiający, który wywołuje narzędzie odpowiednie dla danego systemu plików. Przed jakąkolwiek korektą należy zidentyfikować partycję, zweryfikować jej typ, upewnić się, że nie jest już używana i zachować użyteczną kopię zapasową. Zawsze zaczynam od sprawdzenia braku możliwości zapisu. Naprawa następuje dopiero po tym.

Tux dokładnie sprawdza i naprawia bloki odmontowanego systemu plików Linux.

Zidentyfikuj partycję i jej system plików

/dev/sdb1Kolejność dysków może ulec zmianie po ponownym uruchomieniu lub dodaniu urządzenia USB. Wyświetl typ systemu plików, identyfikator UUID, model, numer seryjny i punkty montowania:

lsblk -o NAZWA,ROZMIAR,STYLF,ID UUID,PUNKTY MONTAŻU,MODEL,NUMER SERIALNY,TYP
sudo blkid

Przewodnik po lsblk pod Linuksem szczegółowo opisuje tę weryfikację. Jeśli pracujesz z LVM, wybierz wolumin logiczny zawierający system plików, na przykład /dev/mapper/vg_data-lv_archive, a nie fizyczny wolumin LVM znajdujący się poniżej. Artykuł poświęcony LVM i jego różne warstwy pozwala nam je rozróżnić.

Następnie sprawdź, w jaki sposób wykorzystywane jest źródło:

findmnt --source /dev/nvme0n1p2
findmnt --target /mnt/data

Sygnał wyjściowy oznacza wzrost głośności. Jeśli go nie ma, nie upewniaj się: przeczytaj ponownie instrukcję. lsblk I znaleźćNastępnie sprawdź UUID. Samouczek na ten temat Identyfikator UUID systemu plików pozwala uniknąć pomylenia dwóch wyników o podobnych nazwach.

Nigdy nie naprawiaj zamontowanego systemu plików

Jądro może modyfikować metadane podczas fsck Spróbuj je naprawić. Dwa widoki systemu plików stają się wówczas niespójne. Montowanie w trybie tylko do odczytu nie jest wystarczającą gwarancją udanej naprawy: narzędzie musi być używane zgodnie z warunkami określonymi w dokumentacji.

Dla danego wolumenu danych zatrzymaj usługi, które go używają, zamknij terminale znajdujące się w drzewie katalogów tego wolumenu, a następnie odmontuj go:



findmnt --source /dev/nvme0n1p2

Jeśli ilość Odpowiada, że ​​cel jest zajęty, nie zmuszaj go. Zidentyfikuj proces za pomocą bezpiecznik Lub następnie należy prawidłowo wyłączyć daną usługę.

W przypadku partycji głównej należy użyć nośnika Live lub środowiska ratunkowego, w którym ta partycja nie jest zamontowana. Samo przełączenie w tryb pojedynczego użytkownika lub awaryjny nie oznacza, że ​​partycja główna jest odmontowana. Na serwerze zdalnym przed ponownym uruchomieniem należy upewnić się, że konsola KVM, IPMI lub dostęp awaryjny dostawcy hostingu są dostępne.

Zacznij od czeku bez wystawiania

Poniższe polecenie pokazuje, który moduł sprawdzający fsck zostanie uruchomiony bez wykonania sprawdzenia:

sudo fsck -N /dev/nvme0n1p2

W zdeasemblowanym systemie ext2, ext3 lub ext4 uruchom wymuszone skanowanie, odpowiadając „nie” na wszystkie proponowane modyfikacje:

sudo e2fsck -f -n /dev/nvme0n1p2
rc=$?
echo "Kod e2fsck: $rc"

Opcja -N zachowuje kontrolę tylko do odczytu. Opcja -F Pełne sprawdzenie jest wymagane nawet wtedy, gdy system plików wydaje się czysty. To sprawdzenie może być czasochłonne w przypadku dużego wolumenu. Jeśli dysk zgłasza błędy wejścia/wyjścia, przekroczenia limitu czasu lub rozłączenia, najpierw należy wykonać kopię zapasową danych, które są jeszcze możliwe do odczytu, a następnie sprawdzić sprzęt. fsck Naprawia strukturę logiczną, a nie dysk, który uległ fizycznej awarii.

Komunikaty jądra mogą potwierdzić ten scenariusz:

Przewodnik po dmesg i błędy jądra pomaga uporządkować te alerty we właściwej kolejności zdarzeń.

Jeśli sprawdzenie wykaże nieścisłości, zweryfikuj kopię zapasową, ponownie potwierdź urządzenie i pozostaw wolumin odmontowany. Następnie uruchom naprawę interaktywną:

sudo e2fsck -f /dev/nvme0n1p2

Przeczytaj każde pytanie przed wysłaniem. Unikaj Domyślnie ta opcja akceptuje wszystkie naprawy, nawet gdy sytuacja wymaga utworzenia kopii zapasowej woluminu lub sprawdzenia sprzętu przed kontynuacją. W przypadku dużej partycji, bezmyślne wykonanie automatycznej naprawy to kiepski kompromis między szybkością a kontrolą.

Po zakończeniu polecenia natychmiast przechwyć jego kod wyjścia:


echo "Kod e2fsck: $rc"

Kod różny od zera nie zawsze oznacza, że ​​naprawa się nie powiodła. Główne wartości to:

  • zero
  • jeden : poprawiono błędy;
  • dwa : błędy poprawiono, wymagane ponowne uruchomienie;
  • cztery : nieskorygowane błędy;
  • osiem : błąd w działaniu testera;
  • szesnaście : błąd użycia lub składni;
  • trzydzieści dwa : kontrola anulowana;
  • sto dwadzieścia osiem : błąd związany z biblioteką współdzieloną.

Wartości te działają jak bity i można je dodawać. Kod cztery wymaga, aby wolumen odczytu/zapisu nie był zwiększany, jakby wszystko było stałe. Kod osiem prośba o sprawdzenie polecenia, typu systemu plików, zainstalowanych narzędzi i wyświetlonych komunikatów.

XFS i Btrfs korzystają z własnych narzędzi

fsck Nie stosuje tej samej metody do wszystkich systemów plików. W przypadku XFS należy rozpocząć od niezmodyfikowanego skanowania odmontowanego woluminu:

sudo xfs_repair -n /dev/nvme0n1p2

Następnie przeprowadza się naprawę za pomocą xfs_repair, zawsze poza montażem. Nie używać Pierwsza próba: zresetowanie dziennika może spowodować utratę ostatnich metadanych.

W przypadku Btrfs ostrożna kontrola jest wyraźnie przeznaczona tylko do odczytu:

sudo btrfs check --readonly /dev/nvme0n1p2

Nie dodawaj --naprawa Bez kopii zapasowej i bez procedury dostosowanej do zaobserwowanego problemu. Sama dokumentacja Btrfs ostrzega przed jego używaniem bez doświadczonego przewodnika. Zawsze sprawdzaj FSTYP lsblk -f przed wyborem narzędzia.

Przed ponownym montażem sprawdź głośność

Po naprawie ext4 uruchom sprawdzanie bez zapisu. Jeśli wynik jest prawidłowy, ponownie zamontuj wolumin, a następnie sprawdź typ, miejsce i nowe komunikaty jądra:

sudo e2fsck -f -n /dev/nvme0n1p2
sudo mount /mnt/data
findmnt /mnt/data

W przypadku partycji głównej kontrolowanej podczas uruchamiania należy również sprawdzić ślady poprzedniego uruchomienia:

dziennikctl -b -1 | grep -Ei 'fsck|system plików|Błąd we/wy|EXT4-fs|XFS|BTRFS'
systemctl --failed

Tam strona podręcznika fsck Opisuje program uruchamiający i jego kody wyjścia. W przypadku ext4 zobacz e2fsckProcedury specyficzne dla XFS i do Btrfs 

sudo apt update && sudo apt upgrade