Co to jest system plików

Wstęp

lsblk na maszynie wirtualnej, nowy dysk sdb o rozmiarze 10G, bez żadnych partycji i bez punktu montowania

Szef dołożył do serwera nowy dysk. Dziesięć gigabajtów. lsblk go widzi. Próbujesz coś na nim zapisać i… nie ma jak. Nie ma folderu, nie ma miejsca na pliki, nic.

Bo nowy dysk to pusta hala magazynowa. Beton, ściany, dach. Żadnych regałów, żadnej kartoteki, żadnych numerków na półkach. Możesz tam wrzucić paczkę, ale za tydzień jej nie znajdziesz.

Dziś wstawiamy do tej hali regały. Poznamy cztery najpopularniejsze rodzaje regałów w świecie Linuksa, założymy każdy z nich, a potem jeden specjalnie zepsujemy i naprawimy.

Uwaga: komendy z tej lekcji niszczą dane na wskazanym urządzeniu. Bez pytania, bez kosza, bez „cofnij”. Dlatego pokazuję wszystko na plikach udających dyski, a Ciebie proszę: ćwicz na maszynie wirtualnej albo na plikach, tak jak ja. Nigdy na laptopie, na którym masz zdjęcia z wakacji.

System plików, czyli regały i kartoteka

Dysk sam z siebie umie tylko jedno: zapisać i odczytać ponumerowane kawałki, tak zwane bloki. Blok numer 1, blok numer 2, blok numer 18 milionów. Nie wie, co to plik. Nie wie, co to folder. Nie wie, że faktura.txt to ważny dokument, a kot.jpg to kot.

System plików to porządek, który zakładamy na tych blokach. Regały, kartoteka i księga. Mówi: tu leżą dane, tu leży spis, tu jest informacja, które półki są wolne. Dzięki niemu możesz powiedzieć „otwórz /srv/dane/faktura.txt”, a nie „daj mi bloki 4711 do 4719”.

Na jednym dysku może być kilka systemów plików, każdy na swojej partycji, o czym w następnej lekcji. A jeden system plików może leżeć na czymś, co dyskiem w ogóle nie jest: na pliku, na kawałku RAM-u albo na dysku w innym kraju.

I-węzły, czyli karty katalogowe

W ostatniej lekcji i-węzły były numerkami w szatni. Teraz zajrzyjmy, co jest na takim numerku.

Wyobraź sobie starą bibliotekę z szufladami pełnymi kart katalogowych. Na każdej karcie: kto jest właścicielem książki, kiedy ją wypożyczono, ile ma stron i na którym regale stoi. Ale uwaga: tytułu na karcie nie ma. Tytuł jest w osobnym spisie, który mówi tylko „»Pan Tadeusz« — karta numer 12”.

W Linuksie karta katalogowa to i-węzeł, po angielsku inode. Spis tytułów to folder.

ls -i /mnt/c57
stat /mnt/c57/faktura.txt

8193 archiwum
  12 faktura.txt
  11 lost+found
  File: /mnt/c57/faktura.txt
  Size: 12          Blocks: 8          IO Block: 4096   regular file
Device: 7,6     Inode: 12          Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Modify: 2026-11-03 22:17:39.627841569 +0100

ls -i pokazuje numer karty przy każdej nazwie. stat pokazuje, co na karcie jest: rozmiar, zajęte bloki, uprawnienia, właściciel, daty, liczba nazw, czyli Links. Nazwy pliku tam nie ma. To dlatego mv w obrębie jednego dysku jest natychmiastowy, nawet dla pliku o rozmiarze stu gigabajtów: przepisuje tylko kartkę w spisie tytułów, książka się nie rusza.

Księgowanie, czyli zeszyt kelnera

Teraz najważniejsza cecha nowoczesnych systemów plików. Pamiętasz kucharza, który realizuje zamówienie? Wyobraź sobie kelnera, który zanim cokolwiek zrobi, zapisuje w zeszycie: „stolik 5, schabowy, zabrać talerz z szóstki”. Dopiero potem idzie do kuchni. Jeśli w połowie zgaśnie prąd, po powrocie zagląda do zeszytu i wie dokładnie, co było w toku. Nie musi obchodzić całej sali i pytać każdego gościa, czy już coś dostał.

To jest dziennik, po angielsku journal, a system plików z dziennikiem to system plików z księgowaniem. Zanim zmieni swój spis, czyli metadane, zapisuje w dzienniku, co zamierza. Po awarii prądu odtwarza albo odrzuca niedokończone wpisy i po kilku sekundach jest spójny.

Bez dziennika, w starym ext2, po każdym twardym wyłączeniu trzeba było przejść całą salę, czyli cały dysk. Na dużych dyskach trwało to długie minuty, a czasem dłużej niż kawa, papieros i druga kawa.

Cztery regały: ext4, XFS, Btrfs, VFAT

ext4 to solidny regał z Ikei, który ma każdy. Czwarta generacja rodziny ext. Domyślny na Ubuntu i Debianie. Umie rosnąć i, co rzadkie, umie się też zmniejszać, ale tylko odmontowany. [Ubuntu]

XFS to regał magazynowy na wózki widłowe. Świetny przy dużych plikach i dużych dyskach. Domyślny system plików w Red Hacie i klonach, czyli Rocky i Alma. Ma jedną wadę, o której trzeba pamiętać: w praktyce da się go tylko powiększać. [RHEL]

Btrfs to regał z wbudowanym aparatem, który robi zdjęcia półek. Ma migawki, sumy kontrolne danych, kompresję i własne podwoluminy. Domyślny na desktopowej Fedorze i w openSUSE. W Red Hat Enterprise Linux go nie ma, więc na RHCSA się nie pojawi.

VFAT to plastikowa skrzynka, którą rozumie każdy: Windows, macOS, telewizor, radio w samochodzie. Pendrive'y, karty pamięci i obowiązkowo partycja rozruchowa EFI na każdym nowoczesnym komputerze. Ale skrzynka jest prosta: nie ma uprawnień Linuksa, nie ma właścicieli, nie ma dowiązań symbolicznych, a w FAT32 jeden plik nie może mieć 4 GB lub więcej. Film w dobrej jakości się nie zmieści. Klasyk.

Zakładamy system plików: mkfs

Polecenie, które stawia regały, to mkfs, „make file system”. Każdy system plików ma swoją wersję: mkfs.ext4, mkfs.xfs, mkfs.vfat, mkfs.btrfs.

Najpierw robię sobie „dyski” z plików. truncate tworzy plik o podanym rozmiarze, który na razie nie zajmuje miejsca:

truncate -s 1G ext4.img xfs.img
truncate -s 100M vfat.img
mkfs.ext4 -L DANE ext4.img

mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 5abe62e4-be1f-4336-bd27-8d7ea200a9d1
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

Czytamy jak raport z budowy: 262 tysiące bloków po 4 kilobajty, 65 536 kart katalogowych, czyli tyle plików zmieści się maksymalnie. Nowe UUID, czyli PESEL. Kopie zapasowe superbloku, o których za chwilę. I dziennik. -L DANE nadaje etykietę, czyli ludzką nazwę.

Na prawdziwym dysku zamiast pliku podajesz urządzenie, na przykład sudo mkfs.ext4 -L DANE /dev/sdb1.

XFS i VFAT:

mkfs.xfs -L DANE xfs.img
mkfs.vfat -n PENDRIVE vfat.img
blkid *.img

ext4.img: LABEL="DANE" UUID="5abe62e4-be1f-4336-bd27-8d7ea200a9d1" BLOCK_SIZE="4096" TYPE="ext4"
vfat.img: SEC_TYPE="msdos" LABEL_FATBOOT="PENDRIVE" LABEL="PENDRIVE" UUID="F6E8-F5AD" BLOCK_SIZE="512" TYPE="vfat"
xfs.img: LABEL="DANE" UUID="6579751f-0522-4609-935a-eecdff964e8f" BLOCK_SIZE="512" TYPE="xfs"

Zwróć uwagę: VFAT ma etykietę przez -n, a nie -L, najwyżej 11 znaków, a jego UUID to krótki numer seryjny, a nie długi identyfikator. Skrzynka plastikowa, mówiłem.

Teraz dwa zabezpieczenia, które warto znać. Spróbujmy założyć XFS na urządzeniu, na którym już jest XFS:

sudo mkfs.xfs /dev/loop7

mkfs.xfs: /dev/loop7 appears to contain an existing filesystem (xfs).
mkfs.xfs: Use the -f option to force overwrite.

XFS odmawia i każe dopisać -f, czyli „force”. A mkfs.ext4 w terminalu zapyta:

/dev/loop6 contains a ext4 file system
        created on Tue Nov  3 22:17:50 2026
Proceed anyway? (y,N)

I tu pułapka. To pytanie pojawia się tylko wtedy, gdy siedzisz przy terminalu. Sprawdziłem: kiedy ta sama komenda idzie ze skryptu albo z rury, mkfs.ext4 nie pyta o nic i po prostu formatuje. Kierowca, który normalnie staje przy pierwszej kontrolce, tym razem jedzie z zamkniętymi oczami. Dlatego w skryptach zawsze najpierw blkid na urządzeniu, a dopiero potem mkfs.

Sprawdzanie i naprawa: fsck i xfs_repair

Regały czasem się krzywią. Awaria prądu, padający dysk, błąd w sterowniku. Do sprawdzania jest fsck, „file system check”. To nakładka, która sama rozpoznaje typ i woła właściwego mechanika: dla ext4 to e2fsck.

Zasada numer jeden, wypisz sobie na czole: system plików musi być odmontowany. Naprawianie regału, z którego ktoś właśnie zdejmuje paczki, kończy się na SOR-ze.

Zróbmy prawdziwą awarię. Na odmontowanym ext4 narzędziem debugfs wycinam plikowi nazwę ze spisu, zostawiając samą kartę katalogową. Sierota: karta jest, tytułu nie ma.

debugfs -w -R "unlink /faktura.txt" /dev/loop6
e2fsck -n /dev/loop6

DANE: clean, 13/65536 files, 12957/262144 blocks

„Clean”. Czysto. A przecież właśnie go zepsułem! e2fsck widzi w nagłówku znaczek „ostatnio odmontowany porządnie” i nie chce mu się sprawdzać. Jak kontroler biletów, który patrzy tylko na to, czy masz ładną minę. Trzeba go zmusić przez -f:

e2fsck -fn /dev/loop6

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 12
Connect to /lost+found? no

Pass 5: Checking group summary information

DANE: ********** WARNING: Filesystem still has errors **********

Jest. -n znaczy „na wszystko odpowiadaj nie”, czyli tylko pokaż, niczego nie zmieniaj. Zawsze zaczynaj od tego. Teraz naprawiamy naprawdę, -y odpowiada „tak” na wszystko:

e2fsck -fy /dev/loop6
echo "kod=$?"

Unattached inode 12
Connect to /lost+found? yes

Inode 12 ref count is 2, should be 1.  Fix? yes

DANE: ***** FILE SYSTEM WAS MODIFIED *****
kod=1

Plik wylądował w folderze lost+found, czyli w biurze rzeczy znalezionych, pod nazwą #12, od numeru karty:

-rw-r--r-- 1 root root 12 Nov  3 22:17 #12
ważne dane

Treść cała, tylko nazwę trzeba nadać od nowa. Teraz już wiesz, po co w każdym ext4 jest ten dziwny folder lost+found.

Kody wyjścia e2fsck się sumują: 0 to brak błędów, 1 to błędy naprawione, 4 to błędy, które zostały, 8 to błąd samego programu. Kciuk w górę ma tu kilka odcieni.

A XFS? Tu wołasz mechanika bezpośrednio, xfs_repair. Najpierw zawsze na sucho:

sudo xfs_repair -n /dev/loop7

Phase 1 - find and verify superblock...
Phase 2 - using internal log
...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

Ciekawostka: fsck na XFS w zwykłym trybie nie robi nic. Dosłownie. fsck.xfs kończy się sukcesem bez sprawdzania (woła xfs_repair dopiero przy wymuszonym sprawdzeniu na starcie, opcją jądra fsck.mode=force), bo XFS naprawia się z dziennika sam przy montowaniu. Jak ktoś Ci powie, że „puścił fsck na XFS i jest czysto”, uśmiechnij się wyrozumiale.

tune2fs: przestawianie regałów bez rozbierania

tune2fs zmienia ustawienia istniejącego ext4 bez kasowania danych. A tune2fs -l wypisuje wszystko o nim:

sudo tune2fs -l /dev/loop6 | grep -E 'volume name|Inode count|Reserved block count|Maximum mount count'

Filesystem volume name:   DANE
Inode count:              65536
Reserved block count:     13107
Maximum mount count:      -1

Pamiętasz rezerwę dla roota z poprzedniej lekcji? 13107 bloków to 5% z 262144. Zmniejszamy do 1% i zmieniamy etykietę:

sudo tune2fs -m 1 /dev/loop6
sudo tune2fs -L ARCHIWUM /dev/loop6

Setting reserved blocks percentage to 1% (2621 blocks)

Maximum mount count: -1 znaczy, że automatyczne sprawdzanie co ileś montowań jest wyłączone. tune2fs -c 30 włączyłoby je co 30 montowań. Na serwerach, które startują raz na pół roku, nikt za tym nie tęskni.

Dla XFS odpowiednikiem jest xfs_admin: sudo xfs_admin -L FILMY /dev/loop7 zmienia etykietę, a xfs_info /punkt/montowania pokazuje parametry.

Jak to działa pod spodem

Każdy system plików ma na początku superblok, czyli stronę tytułową całej księgi: ile jest bloków, ile kart, jaki rozmiar bloku, czy ostatnio wszystko zamknięto porządnie. Jeśli zniszczysz superblok, system plików traci pamięć. Dlatego ext4 trzyma jego kopie w kilku miejscach, to te numery z Superblock backups stored on blocks. e2fsck -b 32768 potrafi wstać z kopii.

Dysk jest podzielony na grupy bloków, a każda grupa ma kawałek tablicy kart i mapę wolnych półek. Dzięki temu dane i ich karty leżą blisko siebie, a głowica starego dysku nie biega z jednego końca na drugi.

A jądro? Jądro nie chce znać szczegółów każdego regału. Ma warstwę pośrednią, VFS, wirtualny system plików. Programy mówią do VFS jednym językiem: otwórz, czytaj, zapisz. VFS tłumaczy to na język ext4, XFS czy Btrfs. Dlatego cp nie musi wiedzieć, czy kopiuje z pendrive'a na XFS. Listę systemów plików, które Twoje jądro rozumie w tej chwili, zobaczysz w cat /proc/filesystems.

Ściąga flag