Najważniejsze zasady, które warto zapamiętać przed naprawą systemu plików
- fsck naprawia system plików, a nie tablicę partycji ani fizyczny dysk.
- Na zamontowanej partycji nie uruchamia się go „na siłę”, zwłaszcza gdy jest to partycja systemowa.
- Dla ext4 najczęściej wystarczy `fsck -f /dev/...` albo bezpośrednio `e2fsck -f`.
- Kod wyjścia `2` oznacza, że po naprawie trzeba zaplanować reboot.
- Przy XFS używa się `xfs_repair`, a przy Btrfs `btrfs check` - zwykły fsck nie załatwia tam wszystkiego.
- Automatyczne sprawdzanie przy starcie zależy od `passno` w `/etc/fstab` oraz parametrów jądra `fsck.mode=force` i `fsck.repair=yes`.
Czym fsck faktycznie zajmuje się w Linuksie
Ja traktuję fsck jako narzędzie do porządkowania metadanych systemu plików, czyli tej warstwy, która opisuje katalogi, inody, wolne bloki i spójność zapisów. W praktyce działa on jak front-end: wybiera właściwy sprawdzacz dla danego typu systemu plików i przekazuje mu zadanie. Dla ext2/3/4 będzie to zwykle e2fsck, a przy innych formatach mechanizm i skutki mogą wyglądać zupełnie inaczej.
To narzędzie przydaje się głównie po nieczystym wyłączeniu, twardym resecie, utracie zasilania albo wtedy, gdy system zgłasza błędy montowania. Przy journalingowych ext3 i ext4 często wystarcza samo odtworzenie dziennika, więc pełna naprawa nie zawsze jest potrzebna. Warto też jasno rozdzielić dwie rzeczy: fsck nie naprawia uszkodzonej tablicy partycji i nie leczy wadliwego dysku. Jeżeli problem leży niżej, trzeba najpierw zdiagnozować sprzęt albo układ partycji.To ważne, bo wiele osób uruchamia fsck w złym miejscu i oczekuje cudu. Ja najpierw ustalam, co jest popsute, a dopiero potem dobieram narzędzie. Dzięki temu nie marnuję czasu na procedurę, która nie rozwiąże źródła problemu.
Skoro wiemy już, co to narzędzie robi, przechodzę do najważniejszego etapu: uruchomienia go bez ryzyka na właściwym urządzeniu.
Jak uruchomić sprawdzanie ręcznie i bezpiecznie
Najbezpieczniejszy schemat jest prosty: identyfikuję urządzenie, upewniam się, że nie jest zamontowane do zapisu, a dopiero potem odpalam sprawdzanie. Przy LUKS albo LVM patrzę na urządzenie po odblokowaniu, na przykład w `/dev/mapper/...`, a nie na surową partycję, bo to właśnie na tym poziomie działa system plików. Jeśli sprawdzam partycję systemową, wolę live USB albo tryb ratunkowy niż kombinowanie na działającym systemie.
Ja zwykle zaczynam od krótkiej weryfikacji, żeby nie pomylić `/dev/sda2` z innym wolumenem:
- `lsblk -f` - pokazuje typ systemu plików i punkt montowania.
- `blkid` - pomaga odczytać UUID i typ partycji.
- `mount` - pozwala sprawdzić, czy wolumin nie jest już aktywny.
Potem dobieram tryb pracy. W praktyce najczęściej używam takich opcji:
| Opcja | Co robi | Kiedy ma sens |
|---|---|---|
| `-N` | Pokazuje, co zostałoby wykonane, bez zmian na dysku. | Gdy chcę sprawdzić plan działania przed ryzykiem. |
| `-n` | Odpowiada „nie” na wszystkie pytania i nic nie poprawia. | Gdy potrzebuję tylko diagnozy. |
| `-p` | Automatycznie naprawia tylko bezpieczne błędy. | Gdy system ma wystartować sam, bez ręcznych decyzji. |
| `-y` | Odpowiada „tak” na wszystko. | Raczej awaryjnie, bo to najbardziej agresywny wariant. |
| `-f` | Wymusza sprawdzenie nawet wtedy, gdy system plików wygląda na czysty. | Gdy chcę pełnej kontroli, a nie tylko szybkiego obejrzenia stanu. |
Przykładowo, przy ext4 najczęściej używam `sudo e2fsck -f /dev/sdXN` albo `sudo fsck -f /dev/sdXN`. Gdy sprawdzam całą konfigurację z `/etc/fstab`, sięgam po `fsck -A`, ale tylko wtedy, gdy wiem, że układ punktów montowania jest już poprawny i nic nie wisi w tle. Jeżeli narzędzie zaczyna pytać o zamontowaną partycję, dla mnie to jasny sygnał, żeby się wycofać i uruchomić procedurę z zewnętrznego nośnika.
Dobrą praktyką jest też wykonanie próby bez zapisu, zanim pozwolę narzędziu cokolwiek poprawiać. To oszczędza nerwy wtedy, gdy problem okazuje się większy niż zwykła niespójność po restarcie. A skoro mamy już samą procedurę, trzeba jeszcze umieć odczytać jej wynik.
Jak czytać wynik naprawy i kiedy reboot jest konieczny
Wynik fsck nie jest prostym „sukces albo porażka”. Szczególnie w rodzinie ext kod wyjścia jest sumą kilku warunków, więc trzeba go czytać świadomie, a nie po samym zerze czy jedynce. Ja patrzę przede wszystkim na to, czy narzędzie tylko posprzątało drobne błędy, czy zostawiło coś nierozwiązanego.
| Kod | Znaczenie | Co robię dalej |
|---|---|---|
| `0` | Nie znaleziono błędów. | Kontynuuję, ale i tak sprawdzam logi, jeśli system wcześniej sprawiał problemy. |
| `1` | Błędy zostały naprawione. | Zwykle wystarczy dalszy start systemu. |
| `2` | Błędy naprawiono, ale potrzebny jest restart. | Planuję reboot możliwie szybko. |
| `4` | Część błędów pozostała nienaprawiona. | Traktuję to jako sygnał do ponownej diagnozy lub pracy z backupu. |
| `8` | Błąd operacyjny. | Sprawdzam, czy wskazałem właściwe urządzenie i czy nie ma problemu z dostępem do nośnika. |
| `16` | Błąd składni lub użycia. | Koryguję komendę. |
| `32` | Użytkownik przerwał działanie. | Wracam do diagnostyki i sprawdzam, co przerwało proces. |
Najważniejsze jest to, że kod nie mówi tylko o błędzie, ale także o stanie po naprawie. Jeśli pojawia się `2`, nie ignoruję tego, nawet gdy system jeszcze „jakoś działa”. Jeżeli widzę `4` albo serię komunikatów o nieudanych operacjach I/O, przestaję myśleć o fsck jako o ostatniej desce ratunku, a zaczynam szukać przyczyny głębiej.
Po odczytaniu wyniku przechodzę do pytania, które w praktyce oszczędza najwięcej czasu: czy to na pewno problem systemu plików, czy już raczej dysku albo samego układu partycji. I właśnie od tego zależy dalszy ruch.
Kiedy fsck nie wystarczy i trzeba sięgnąć po inne narzędzia
Jeżeli błąd wraca po każdym restarcie, nie zakładam automatycznie, że system plików jest „zły z natury”. Często prawdziwym źródłem problemu jest dysk, kontroler, kabel, obudowa USB albo pamięć RAM. W takich sytuacjach naprawa metadanych tylko maskuje objaw, a nie usuwa przyczyny.
Ja stawiam granicę w trzech miejscach:
- Gdy pojawiają się błędy odczytu lub zapisu na poziomie I/O, najpierw kopiuję dane.
- Gdy partycja jest widoczna, ale tablica partycji jest uszkodzona lub zmieniona, fsck nie pomoże.
- Gdy nośnik zgłasza coraz więcej błędów SMART albo realokacji sektorów, traktuję to jako problem sprzętowy.
To też dobry moment na rozróżnienie: fsck nie jest narzędziem do naprawy całego „dysku”, tylko samego systemu plików na partycji. Jeśli uszkodzona jest struktura GPT albo MBR, potrzebujesz narzędzi do partycjonowania lub odzyskiwania układu partycji. Jeśli problem dotyczy fizycznej powierzchni nośnika, sama naprawa logiczna nie zmieni faktu, że sprzęt może dalej sypać błędami.
W praktyce zawsze trzymam się tej kolejności: najpierw zabezpieczam dane, potem diagnozuję sprzęt, a fsck zostawiam jako narzędzie do przywracania spójności. To podejście jest mniej efektowne niż szybkie „napraw wszystko”, ale po prostu działa lepiej. Gdy już wiem, że problem dotyczy konkretnego formatu, warto dopasować do niego właściwe narzędzie.
Różnice między ext4, XFS i Btrfs
Nie każdy system plików zachowuje się tak samo, a tu właśnie najłatwiej o pomyłkę. Na ext4 fsck jest naturalnym wyborem, ale przy XFS i Btrfs trzeba myśleć inaczej. Ja traktuję to jak wybór odpowiedniego klucza do konkretnego zamka, bo uniwersalne podejście kończy się zwykle stratą czasu albo ryzykiem większych uszkodzeń.
| System plików | Właściwe narzędzie | Co warto zapamiętać |
|---|---|---|
| ext2 / ext3 / ext4 | `fsck` albo `e2fsck` | To najbardziej klasyczny scenariusz; journaling często ogranicza zakres naprawy. |
| XFS | `xfs_repair` | `fsck.xfs` kończy się sukcesem, ale nic realnie nie naprawia; XFS wymaga własnego narzędzia. |
| Btrfs | `btrfs check` | `fsck.btrfs` nie jest pełnoprawną naprawą; tryb repair trzeba stosować bardzo ostrożnie. |
Najważniejsza różnica między tymi systemami polega na filozofii odzyskiwania spójności. XFS zakłada recovery przy montowaniu i używa `xfs_repair`, a nie klasycznego fsck. Btrfs ma własne narzędzie do sprawdzania spójności i nie powinien być traktowany jak ext4 z inną nazwą. To właśnie dlatego ja zawsze sprawdzam typ systemu plików przed jakąkolwiek naprawą, zamiast zgadywać po przyzwyczajeniu.
Znając te różnice, łatwiej też zrozumieć, dlaczego system czasem nie uruchamia sprawdzania tak, jak ktoś oczekuje. To prowadzi już prosto do automatyki przy starcie systemu.
Jak wymusić sprawdzenie przy starcie systemu
Na współczesnych dystrybucjach z systemd automatyczne sprawdzanie zależy od tego, co wpisano w `/etc/fstab`. Gdy `passno` ma wartość większą od zera, system może uruchomić check przy starcie, o ile partycja ma się normalnie montować i nie ma flagi `noauto`. Root jest sprawdzany jako pierwszy, a pozostałe systemy plików mogą być obsługiwane równolegle, chyba że leżą na tym samym fizycznym dysku i trzeba unikać kolizji.
Ja w praktyce rozróżniam trzy tryby pracy, które naprawdę mają znaczenie:
- `fsck.mode=auto` - domyślne zachowanie, gdy checker sam decyduje, czy sprawdzać.
- `fsck.mode=force` - wymusza pełne sprawdzenie przy starcie.
- `fsck.mode=skip` - pomija sprawdzanie całkowicie.
Do tego dochodzi `fsck.repair`:
- `preen` - naprawia tylko bezpieczne rzeczy,
- `yes` - odpowiada „tak” na wszystko,
- `no` - nie podejmuje napraw.
Jeżeli chcę jednorazowo wymusić kontrolę przy kolejnym uruchomieniu, wolę właśnie parametry jądra niż stare, niejednoznaczne obejścia. To daje większą przewidywalność i lepiej pasuje do dzisiejszego sposobu startu systemu. Po ustawieniu takiej kontroli zostaje już tylko ostatni krok: upewnić się, że naprawa faktycznie rozwiązała problem.
Co sprawdzić po udanej naprawie, żeby problem nie wrócił
Po udanym fsck nie kończę pracy od razu. Najpierw sprawdzam, czy system montuje partycję bez błędów, a potem patrzę do logów startu i bieżącego kernela, żeby zobaczyć, czy nie ma śladów głębszego problemu. Jeśli wcześniej pojawiały się komunikaty o I/O, robię też szybki przegląd stanu dysku i upewniam się, że kopia zapasowa jest aktualna.
- Potwierdzam, że partycja montuje się normalnie i bez trybu awaryjnego.
- Sprawdzam, czy po restarcie nie wracają te same komunikaty o błędach.
- Jeśli naprawa była większa, obserwuję nośnik przez najbliższe uruchomienia.
- Gdy problem wraca, zakładam awarię sprzętową, a nie jednorazową korupcję metadanych.
To podejście jest mniej spektakularne niż szybkie uruchomienie narzędzia, ale daje lepszy efekt końcowy. Dla mnie fsck jest skuteczne wtedy, gdy działa jako część większej diagnostyki, a nie jako samotna odpowiedź na każdy problem z dyskiem. Jeśli po dwóch kolejnych uruchomieniach błędy nadal wracają, traktuję dysk jako kandydata do wymiany, a nie do kolejnej rundy napraw.
