Porównanie systemów plików w Linuxie: ext4, XFS i Btrfs w praktyce

Po co w ogóle wybierać system plików świadomie

System plików jako kluczowy element całego stosu

System plików w Linuksie jest pośrednikiem między aplikacją a fizycznym nośnikiem danych. To on decyduje, jak dokładnie zostaną rozmieszczone pliki na dysku, jak będą zapisywane metadane, jak działa dziennik oraz jak łatwo będzie później odtworzyć spójny stan danych po awarii. Z poziomu aplikacji wszystko wygląda podobnie: jest ścieżka, plik, katalog. Prawdziwa różnica zaczyna się dopiero niżej, na poziomie ext4, XFS czy Btrfs.

Źle dobrany system plików może sprawić, że nawet bardzo szybki dysk NVMe będzie wykorzystywany w połowie, a operacje losowego I/O zamienią się w wąskie gardło. Można też mieć perfekcyjnie zbudowaną macierz RAID, a mimo to kopiowanie wielu małych plików będzie żałośnie wolne, bo system plików nie radzi sobie z ich liczbą lub fragmentacją.

Konsekwencje złego wyboru w praktyce

Różnice między ext4, XFS i Btrfs nie są wyłącznie akademickie. W praktyce błędny wybór przekłada się na konkretne problemy:

• spadek wydajności w określonych scenariuszach (np. baza danych na nieoptymalnym systemie plików),
• kłopoty z czasem startu systemu po nieczystym wyłączeniu (długotrwałe fsck),
• brak łatwego mechanizmu „cofnięcia się” po nieudanej aktualizacji (brak snapshotów),
• utrudnione lub bardzo czasochłonne odzyskiwanie danych po awarii dysku,
• nieoptymalne wykorzystanie SSD/NVMe (brak odpowiedniego alignowania, brak kompresji czy TRIM).

Jeśli cała infrastruktura produkcyjna stoi na jednym typie systemu plików „bo tak było w poradniku sprzed 10 lat”, to prędzej czy później trafi się scenariusz, w którym to ograniczenie uderzy po kieszeni – czy to w postaci dłuższych przestojów, czy kosztownych migracji.

Różne potrzeby: laptop, NAS, serwer bazodanowy i host kontenerów

System plików „idealny do wszystkiego” nie istnieje. Desktopowy użytkownik szukający szybkiego startu systemu, sprawnej obsługi wielu małych plików i prostego odzyskiwania danych ma inne potrzeby niż administrator hostujący dziesiątki maszyn wirtualnych, których dyski są pojedynczymi, ogromnymi plikami.

Dla domowego NAS-a, gdzie króluje streaming multimediów i kopie zapasowe zdjęć, kluczowe są duże, sekwencyjne transfery i odporność na uszkodzenia. Dla serwera bazodanowego – niski latency, dobre wykorzystanie cache, stabilność przy intensywnym, losowym I/O oraz przewidywalne zachowanie dziennika. Host kontenerów z kolei zyskuje na systemie plików, który dobrze radzi sobie z dużą liczbą inode’ów, snapshotami i subwolumenami.

Anegdota: „domyślny ext4” i szkoła życia

Częsty scenariusz wygląda tak: nowy serwer, instalacja Linuksa, wszystko „Next, Next, Finish”, domyślny ext4, jeden duży system plików na wszystko. Działa? Działa. Do momentu, aż trzeba:

• cofnąć się po błędnej aktualizacji,
• szybko odtworzyć setki gigabajtów danych po awarii,
• zoptymalizować wydajność bazy danych albo maszyn wirtualnych.

Krótkie przypomnienie: jak działa system plików w Linuxie

Inody, bloki i dziennik – fundamenty

Każdy z omawianych systemów plików – ext4, XFS i Btrfs – korzysta z podobnych konceptów, choć realizuje je inaczej. Inode to struktura przechowująca metadane pliku: prawa dostępu, właścicieli, czasy modyfikacji oraz wskaźniki do bloków z danymi. Dane pliku znajdują się w blokach o określonym rozmiarze (typowo 4 KB), a system plików zarządza powiązaniem inode → bloki.

Dziennik (journal) to mechanizm, dzięki któremu po nagłej utracie zasilania system nie musi skanować całego dysku w poszukiwaniu niespójności. Operacje są zapisywane w dzienniku, a dopiero później „odgrywane” na docelowych strukturach. Ext4 i XFS stosują journaling (choć w różny sposób), natomiast Btrfs wykorzystuje mechanizm Copy-on-Write, który częściowo zastępuje tradycyjny journal.

Rola VFS i przezroczystość dla aplikacji

VFS (Virtual File System) w jądrze Linuksa jest warstwą abstrakcji, która pozwala aplikacjom pracować z jednolitym interfejsem plików, niezależnie od konkretnego systemu plików. Dzięki temu program nie musi wiedzieć, czy plik jest zapisany na ext4, XFS, Btrfs, czy nawet na NFS lub Ceph.

To, że aplikacje „nie widzą” konkretnego systemu plików, jest jednocześnie błogosławieństwem i przekleństwem. Łatwiej pisać przenośne programy, ale administratorzy muszą świadomie dobrać system plików do typu obciążenia, bo sama aplikacja nie zrekompensuje złej decyzji na niższym poziomie.

Sprzęt, IOPS i realne ograniczenia wydajności

Na wydajność systemu plików wpływa nie tylko jego implementacja, ale również parametry sprzętu: rodzaj dysku (HDD vs SSD vs NVMe), kontroler, cache, a także konfiguracja RAID. Kluczowe pojęcia to:

• IOPS – liczba operacji wejścia/wyjścia na sekundę, istotna zwłaszcza przy małych plikach,
• opóźnienia (latency) – czas odpowiedzi na pojedynczą operację,
• rozmiar bloku – dopasowanie do typowego rozmiaru plików i do strony pamięci,
• cache w RAM – system plików i jądro korzystają z buforowania w pamięci, co może maskować problemy do momentu, aż zabraknie RAM-u.

Na SSD i NVMe znaczenie ma także wyrównanie (alignowanie) partycji do granic bloków fizycznych nośnika. Nieprawidłowy alignment powoduje, że pojedynczy logiczny zapis 4 KB może wymagać dwóch fizycznych zapisów na dysku, co degraduje wydajność i skraca żywotność SSD. Przy planowaniu partycjonowania pod system plików lepiej od razu zadbać o poprawne wyrównanie (np. start partycji od 1 MiB i używanie narzędzi, które domyślnie wyrównują do 4K).

ext4 – sprawdzony koń pociągowy

Charakterystyka i dojrzałość ext4

Ext4 jest bezpośrednim następcą ext3, a pośrednio także ext2. Wraz z kolejnymi wersjami dodawano nowe funkcje (extent, większe rozmiary systemu plików, poprawiony journaling), jednocześnie zachowując pewną ciągłość, dzięki której ext4 jest postrzegany jako „bezpieczna” i przewidywalna opcja. To wciąż domyślny wybór w wielu dystrybucjach Linuksa, szczególnie dla partycji root oraz prostych serwerów.

Na ext4 działają miliony instalacji desktopowych, tysiące małych VPS-ów oraz niezliczone urządzenia embedded. Narzędzia takie jak fsck.ext4, resize2fs, tune2fs są dobrze przetestowane i dostępne praktycznie wszędzie. Dla mniej zaawansowanych użytkowników oznacza to mniejszą szansę na zderzenie z egzotycznym błędem.

Mechanizmy techniczne ext4 w praktycznym użyciu

Ext4 wprowadził extent, czyli sposób przechowywania informacji o blokach danych bardziej zbliżony do „zakresów” niż pojedynczych bloków. Dzięki temu system lepiej radzi sobie z dużymi plikami i ogranicza fragmentację. Do tego dochodzi delayed allocation, czyli opóźnione przydzielanie bloków – jądro czeka z faktycznym przydziałem miejsca, aby zoptymalizować rozmieszczenie danych w jednym ciągłym obszarze.

Dziennik ext4 może pracować w kilku trybach:

• data=ordered – domyślny kompromis między bezpieczeństwem a wydajnością, zapewnia uporządkowanie zapisu danych i metadanych,
• data=journal – wpisywane są zarówno dane, jak i metadane; najwyższa spójność, ale większe obciążenie I/O,
• data=writeback – najszybszy, ale o najmniejszej gwarancji spójności danych po awarii.

Opcje montowania typu noatime lub relatime potrafią zauważalnie odciążyć dysk w systemach, gdzie odczyt plików nie wymaga dokładnego śledzenia czasu ostatniego dostępu. Przy podstawowym desktopie relatime zazwyczaj wystarcza, lecz na dyskach SSD stosuje się często noatime, aby zminimalizować liczbę niepotrzebnych zapisów.

ext4 a różne typy obciążenia

Ext4 całkiem dobrze radzi sobie zarówno z dużą liczbą małych plików, jak i z dużymi plikami sekwencyjnymi. W przypadku ogromnych katalogów (setki tysięcy plików) może jednak ustępować lepiej zoptymalizowanym strukturom katalogów XFS. Mimo to na typowym desktopie czy małym serwerze plików różnica bywa niezauważalna.

Przy obciążeniu typowo serwerowym ext4 zwykle dobrze się zachowuje, dopóki nie przekraczamy wieluset gigabajtów czy kilku terabajtów na pojedynczy system plików. Potem coraz bardziej daje się we znaki czas ewentualnego fsck, a także ograniczenia w zarządzaniu ogromną ilością metadanych. To jeden z powodów, dla których na dużych macierzach częściej spotyka się XFS.

Kiedy ext4 jest idealny, a kiedy szukać alternatywy

Ext4 sprawdza się znakomicie w scenariuszach:

• desktop i laptop – rootfs, /home, proste partycje danych,
• małe VPS-y – tam, gdzie liczy się przewidywalność i kompatybilność narzędzi,
• serwery o umiarkowanej skali – gdy wolumeny nie są gigantyczne, a snapshoty realizuje się na poziomie LVM lub hypervisora.

Jednocześnie ext4 ma swoje ograniczenia:

• brak natywnych snapshotów (trzeba sięgać po LVM lub rozwiązania zewnętrzne),
• brak wbudowanego RAID – wymaga MD, LVM, macierzy sprzętowej,
• brak wbudowanej kompresji,
• czasochłonne fsck przy naprawdę dużych wolumenach.

XFS – specjalista od dużych wolumenów i strumieni danych

Pochodzenie XFS i pierwotne założenia

XFS powstał pierwotnie w systemie IRIX firmy SGI jako system plików dedykowany dużym, wydajnym stacjom roboczym i serwerom. Projektowano go z myślą o macierzach dyskowych, dużych plikach i wysokim poziomie równoległości I/O. Z czasem został przeniesiony do Linuksa i zyskał status jednego z kluczowych systemów plików klasy enterprise.

W wielu dystrybucjach serwerowych XFS jest domyślnym wyborem dla dużych wolumenów danych – na przykład pod /var/lib, gdzie przechowuje się bazy danych czy obrazy maszyn wirtualnych. Firmy stawiające na wysoką przepustowość strumieni danych (backupy, logi, archiwizacja) bardzo często decydują się właśnie na XFS.

Struktury danych i skalowanie XFS

XFS intensywnie korzysta z B-drzew oraz zaawansowanej alokacji extentów, co pozwala mu sprawnie zarządzać bardzo dużymi plikami oraz ogromnymi katalogami. Struktury są zaprojektowane tak, aby dobrze skalować się w scenariuszach z wieloma równoległymi wątkami zapisującymi dane. System potrafi przydzielać przestrzeń w wielu obszarach jednocześnie, co zmniejsza ryzyko wąskich gardeł przy zapisie.

Jedną z kluczowych cech XFS jest brak możliwości zmniejszania rozmiaru systemu plików – można go jedynie powiększać. To decyzja projektowa związana z tym, jak rozmieszczone są dane i metadane. W praktyce oznacza to konieczność zachowania pewnego zapasu przy projektowaniu wielkości wolumenów oraz stosowania warstwy LVM lub podobnej, żeby mieć większą elastyczność w razie przyszłych zmian.

Dopiero pod presją czasu okazuje się, że snapshotów brak, fsck na kilkudziesięcioterabajtowym systemie może trwać godzinami, a migracja na inny system plików „na gorąco” nie jest specjalnie wygodna. Odpowiedni wybór na starcie zwykle jest tańszy niż późniejsze ratowanie sytuacji. Blogi technologiczne typu 4komputery co jakiś czas przypominają takie historie w różnych kontekstach – i niestety, rzadko są one czysto teoretyczne.

Opcje montowania XFS w praktyce

XFS oferuje szereg opcji montowania, które pozwalają dostroić system do konkretnego sprzętu i obciążenia. Kilka praktycznych przykładów:

Typowe scenariusze użycia XFS

XFS najlepiej czuje się tam, gdzie dane lecą szerokim strumieniem, a nie kapie po kilka kilobajtów. Kilka sytuacji, w których praktycy sięgają po ten system niemal odruchowo:

• Duże magazyny danych – wolumeny rzędu wielu terabajtów na macierzach RAID (sprzętowych lub MD/LVM), repozytoria kopii zapasowych, archiwa logów.
• Obrazy VM i kontenerów – katalogi typu /var/lib/libvirt/images lub /var/lib/containers, gdzie dominuje zapis/odczyt dużych plików qcow2/raw.
• Strumieniowanie multimediów – serwery wideo, systemy monitoringu wizyjnego, gdzie trwa ciągły zapis dużych plików.
• Analiza danych – klastry z narzędziami typu Hadoop/Spark trzymającymi lokalne scratch space na XFS.

Przykładowo, na serwerze backupowym z kilkunastoma dyskami w RAID-6 XFS potrafi wycisnąć więcej z kontrolera niż ext4, zwłaszcza przy kilku równoległych zadaniach kopii. Z kolei na małym VPS-ie różnicy często nie będzie – i to też jest uczciwa informacja.

Ograniczenia i pułapki XFS

Obok zalet XFS ma zestaw cech, które mogą zaskoczyć z przyzwyczajenia do ext4 czy Btrfs. Dobrze je znać, zanim pod systemem plików wylądują kluczowe dane.

• Brak zmniejszania rozmiaru – jeśli przydzielisz 10 TB i używasz 2 TB, reszta po prostu czeka. Korekta wymaga migracji danych lub przebudowy wolumenu.
• Bez snapshotów i RAID w samym FS – migawki i nadmiarowość to zadanie LVM, macierzy sprzętowej, Cepha itp.
• Wrażliwość na niektóre błędy sprzętowe – jak każdy system plików nastawiony na wydajność, nie lubi udawanych zapisów „z bufora” w tanich kontrolerach bez BBU.
• Trim i SSD – trzeba świadomie użyć discard lub okresowego fstrim, żeby sensownie współpracował z nośnikami flash.

Spotykaną dawniej opinię, że XFS „nie lubi” baz danych, należy traktować jako historyczną. Współczesne wydania radzą sobie bardzo dobrze, o ile trzyma się zdrowego rozsądku: prawidłowo dobrany logbsize, rozsądne noatime, poprawnie skonfigurowany RAID pod spodem.

XFS a konkretne typy obciążeń

W praktyce XFS zwykle wygrywa tam, gdzie:

• dominują duże pliki i sekwencyjny I/O,
• wolumen jest duży (wiele TB) i ma rosnąć jeszcze bardziej,
• liczy się dobra równoległość przy wielu wątkach zapisu.

Przy setkach tysięcy małych plików w jednym katalogu XFS potrafi utrzymać przyzwoitą responsywność nawet wtedy, gdy ext4 zaczyna już „chrupać” przy listowaniu. Nie znaczy to, że zawsze będzie spektakularnie szybszy – zyski są mocno zależne od konfiguracji RAID, kontrolera i wzorca I/O.

Do prostego /home czy laptopa XFS nie daje zwykle realnego zysku względem ext4, a zarazem komplikujesz sobie potencjalną migrację (np. do dystrybucji, które domyślnie używają ext4 i mają wokół niego najwięcej narzędzi). Tam, gdzie nie ma potrzeby posiadania gigantycznych wolumenów, XFS jest bardziej „miłym dodatkiem” niż koniecznością.

Praktyczne wskazówki konfiguracji XFS

Przy tworzeniu systemu plików XFS na macierzy RAID lub pod LVM dobrze:

• określić rozmiar bloku i alignment tak, by pasowały do stripe size macierzy,
• użyć odpowiednich parametrów mkfs.xfs (np. -d su=, sw=) przy bardziej zaawansowanych konfiguracjach,
• zaplanować wolumeny tak, by realnie nie trzeba było ich zmniejszać (przydaje się LVM i elastyczne LV),
• zapewnić sensowny monitoring – w szczególności miejsca na log i zachowania przy błędach I/O.

Na serwerze z VM-ami dobrym kompromisem bywa XFS na LVM, a snapshoty robi się na poziomie LVM lub hypervisora. XFS skupia się na szybkim i równoległym I/O, a resztę pracy biorą na siebie wyższe warstwy.

Btrfs – snapshoty, kompresja i nowoczesne funkcje

Filozofia Btrfs i segment „next-gen”

Btrfs powstał jako próba zbudowania „ZFS-a dla Linuksa” bez problemów licencyjnych – system plików, który nie jest tylko prostą warstwą nad blokami, lecz całą platformą do zarządzania danymi. Snapshoty, subwolumeny, kompresja, kontrola integralności, wbudowany RAID, wysyłanie przyrostowe – to wszystko jest częścią jednego projektu.

Nie jest to już ciekawostka z eksperymentalnych repozytoriów. Od lat Btrfs jest stabilnie używany w wielu dystrybucjach – od rolek na desktopie po serwery plików – choć konkretne funkcje (zwłaszcza RAID5/6) nadal mają swój rozdział „uwagi i ostrzeżenia”.

Copy-on-write i snapshoty Btrfs w praktyce

Sercem Btrfs jest copy-on-write (CoW). Przy zapisie nie nadpisuje się istniejących bloków, ale tworzy nowe wersje danych i metadanych. To pozwala na:

• błyskawiczne snapshoty – migawka to głównie nowy zestaw wskaźników do tych samych bloków; zapis rośnie dopiero, gdy pojawiają się zmiany,
• bezpieczniejsze aktualizacje – można zaktualizować system na migawce, a w razie problemów wrócić do poprzedniego stanu kilkoma komendami,
• wydajny backup przyrostowy – mechanizm btrfs send/receive przesyła tylko różnice między snapshotami.

Typowy scenariusz na serwerze aplikacyjnym wygląda tak: przed aktualizacją tworzony jest snapshot subwolumenu / i np. /var. Jeśli update zadziała – stare snapshoty są usuwane po kilku dniach. Jeśli coś eksploduje, rollback jest znacznie szybszy niż ręczne odtwarzanie backupu.

Subwolumeny, layout i organizacja danych

Btrfs wprowadza pojęcie subwolumenów, które zachowują się trochę jak osobne systemy plików, ale nadal są częścią tej samej przestrzeni danych. Ułatwia to dopasowanie polityki snapshotów i kompresji do różnych części systemu.

Popularny układ na desktopie lub serwerze z Btrfs wygląda następująco:

• osobny subwolumen dla / (system),
• osobny dla /home,
• osobne subwolumeny dla katalogów intensywnie zapisujących logi i cache, np. /var/log, /var/cache,
• opcjonalnie dodatkowe subwolumeny dla danych aplikacji (np. /var/lib/docker, /var/lib/libvirt).

Dzięki temu snapshoty / nie zawsze muszą obejmować /home, a kompresja może być włączona np. dla /home (mnóstwo tekstu i kodu), ale wyłączona dla katalogu z obrazami maszyn wirtualnych, gdzie zysk byłby znikomy.

Kompresja transparentna – lzo, zstd i wybór algorytmu

Btrfs oferuje kompresję transparentną, włączaną już na poziomie opcji montowania. Najczęściej używane algorytmy to:

• LZO – szybka, dość lekka, daje umiarkowany stopień kompresji,
• Zstd – nowocześniejsza, zwykle lepszy stosunek kompresji do kosztu CPU, dostępna z poziomami (np. zstd:1, zstd:3).

Przy katalogach pełnych logów, plików tekstowych i konfiguracji kompresja potrafi naprawdę ściąć zużycie miejsca. Na desktopie efekt bywa taki, że „magicznie” mieści się więcej projektów i VM-ek bez kupowania kolejnego SSD. Z kolei dla danych już skompresowanych (wideo, archiwa) kompresja generuje głównie niepotrzebny narzut CPU, dlatego dla takich subwolumenów lepiej ją wyłączyć.

Kontrola integralności i checksummy

Każdy blok danych i metadanych w Btrfs ma sumę kontrolną. System plików wie więc, czy odczytane dane są takie, jak zapisane. Przy użyciu redundancji (RAID1, RAID10) Btrfs może wykrywać i automatycznie naprawiać tzw. bit rot – ciche uszkodzenia sektorów, które nie powodują natychmiast błędu I/O, ale niszczą dane.

Od czasu do czasu można uruchomić btrfs scrub, który przechodzi przez dane, sprawdza sumy kontrolne i – jeśli jest z czego – odtwarza uszkodzone bloki z nadmiarowej kopii. Przy długoterminowym przechowywaniu ważnych danych to bardzo przydatny „odkurzacz”.

Wbudowany RAID i elastyczność alokacji

Btrfs potrafi samemu zarządzać kilkoma urządzeniami blokowymi, realizując różne poziomy nadmiarowości. Najczęściej używane w dzisiejszych wdrożeniach są:

• RAID1 – mirroring danych i metadanych na dwóch lub więcej dyskach,
• RAID10 – łączy striping z mirroringiem, dla większej wydajności i odporności,
• single – brak redundancji, ale nadal działają snapshoty, kompresja, checksummy.

Konfiguracje RAID5/6 istnieją, lecz w wielu miejscach wciąż można spotkać ostrzeżenia o potencjalnych problemach z odtwarzaniem i spójnością. Jeśli nie ma dobrego powodu, lepiej trzymać się RAID1/10 albo użyć klasycznego MD/LVM pod spodem i Btrfs tylko na pojedynczym wolumenie logicznym.

Ciekawą cechą Btrfs jest możliwość dynamicznej zmiany układu danych. Można np. dodać dysk do puli, a następnie wykonać btrfs balance, aby rozłożyć dane na więcej urządzeń i przejść z układu single na RAID1 – bez kopiowania wszystkiego „ręcznie” na zewnątrz.

Typowe obciążenia, w których Btrfs błyszczy

Największe korzyści Btrfs widać tam, gdzie snapshoty i kompresja realnie upraszczają życie:

• Serwery aplikacyjne i webowe – snapshoty przed wdrożeniami, szybki rollback, kompresja logów i kodu.
• Desktop deweloperski – częste instalacje/aktualizacje pakietów, snapshoty na wypadek popsucia systemu, kompresja kodu źródłowego i środowisk wirtualnych.
• NAS-y domowe i małe firmowe – snapshoty współdzielone po NFS/SMB, oszczędność miejsca na dokumentach i zdjęciach, wysyłanie przyrostowe na backup offline.

Prosty przykład: mały serwer plików na dwóch dyskach SSD w RAID1, z Btrfs i włączoną kompresją zstd. Snapshoty /data wykonują się co godzinę, a przenoszenie zmian na drugi serwer (offsite) odbywa się przez btrfs send/receive. W praktyce backup przyrostowy zajmuje niewiele miejsca i kończy się zwykle zanim zdąży ostygnąć kawa.

Jeśli więc planowana jest bardziej zaawansowana architektura z częstymi snapshotami, kompresją i integracją z subwolumenami, rozsądniej jest rozważyć Btrfs. Jeżeli z kolei chodzi o ogromne wolumeny danych na macierzach RAID – XFS potrafi być lepszym wyborem, szczególnie w połączeniu z dobrym planowaniem LVM – zarządzanie przestrzenią dyskową, które pozwala później elastycznie powiększać wolumeny i optymalizować układ partycji.

Pułapki, ograniczenia i zdrowy sceptycyzm

Btrfs nie jest magicznym młotkiem do każdego gwoździa. Kilka realnych ograniczeń i rzeczy, o których lepiej wiedzieć:

• RAID5/6 – wciąż nie jest polecany do krytycznych zastosowań, dopóki dokumentacja i praktyka nie zaczną go traktować jako w pełni „nudny” i przewidywalny.
• Fragmentacja pod obciążeniem CoW – intensywne zapisywanie do tych samych plików (np. duże bazy danych) na domyślnym CoW może prowadzić do fragmentacji i spadku wydajności.
• Większe skomplikowanie narzędzi – btrfs send/receive, balance, scrub, subwolumeny – to daje ogromne możliwości, ale też wymaga oswojenia.

Przy bazach danych lub VM-kach dobrym kompromisem jest wyłączenie CoW na konkretnym katalogu (atrybut chattr +C) lub stworzenie subwolumenu montowanego z nodatacow, a resztę systemu pozostawić z pełnym CoW i snapshotami. Wtedy zyskuje się zalety Btrfs, jednocześnie nie wpychając CoW tam, gdzie bardziej przeszkadza niż pomaga.

Praktyczne zasady konfiguracji Btrfs

Planowanie wdrożenia Btrfs sprowadza się w dużej mierze do sensownego podziału systemu na subwolumeny i dobrania opcji montowania. Kilka praktycznych wytycznych:

• wydziel osobne subwolumeny dla /, /home i intensywnie zapisujących katalogów (/var/log, /var/cache),
• włącz kompresję (np. compress=zstd:1) dla subwolumenów z tekstem i typowymi plikami użytkowników,

Strategie migracji: ext4/XFS do Btrfs bez niepotrzebnego dramatu

Przejście z ext4 lub XFS na Btrfs najczęściej oznacza klasyczny taniec: backup, przeformatowanie, odtworzenie danych. Bez sztuczek na żywym organizmie, za to przewidywalnie.

Przykładowy scenariusz dla partycji danych:

1. Wykonanie pełnego backupu (rsync, borg, restic – co kto lubi).
2. Sprawdzenie, ile miejsca faktycznie jest używane i czy backup rzeczywiście się odtwarza.
3. Przeformatowanie partycji na Btrfs z założeniem od razu docelowego RAID (jeśli ma dotyczyć tej warstwy).
4. Odtworzenie danych i dopiero potem zabawa w subwolumeny, kompresję i snapshoty.

Na serwerach lepiej nie mieszać na raz wszystkich eksperymentów. Sensowna kolejność:

• najpierw przejście z ext4/XFS na „proste” Btrfs (bez RAID, bez agresywnej kompresji),
• obserwacja zachowania przy normalnym obciążeniu,
• dopiero potem dokładanie kompresji, rozbudowa puli o kolejne dyski, automatyczne snapshoty.

Na desktopie margines błędu jest większy, ale i tak dobrym zwyczajem jest posiadanie przynajmniej jednego zewnętrznego backupu przed pierwszym poważniejszym „remontem” systemu plików. Snapshoty są świetne, lecz nie zastępują kopii offline – szczególnie, gdy ransomware ma dostęp do tej samej maszyny.

Jak wybierać system plików pod konkretne zastosowania

Decyzja „ext4, XFS czy Btrfs?” jest bardziej o profilu obciążenia niż o wierze w jedyne słuszne rozwiązanie. Kilka praktycznych wzorców:

• Prosty VPS, pojedynczy dysk, mało danych krytycznych – ext4 nadal jest dobrym, nudnym wyborem. Ma być stabilnie, przewidywalnie i bez konieczności myślenia o narzędziach do snapshotów.
• Serwer z dużym wolumenem na logi, backupy, media – XFS lub Btrfs. XFS, jeśli priorytetem są proste, wysokowydajne sekwencyjne zapisy i minimalna liczba „ficzerów”. Btrfs, jeśli przydadzą się snapshoty i kompresja.
• Desktop / laptop deweloperski – Btrfs jako root + subwolumeny to wygoda przy aktualizacjach i testowaniu nowych wersji dystrybucji. Można bez stresu psuć system i wracać do poprzedniej migawki.
• Serwer baz danych – XFS lub ext4 na partycji z danymi, ewentualnie Btrfs z wyłączonym CoW na katalogu bazy. Kluczowe jest przewidywalne IOPS i opóźnienia, a nie fajerwerki z snapshotów.
• NAS domowy / mała firma – Btrfs daje duży komfort: snapshoty współdzielone przez NFS/SMB, przyrostowe backupy, checksummy. Dla większych środowisk często łączy się go z klasycznym RAID-em sprzętowym lub MD, zamiast polegać na RAID5/6 Btrfs.

W praktyce w jednej infrastrukturze spokojnie współistnieje kilka systemów plików. Na przykład /boot i root na ext4, partycja pod bazę danych na XFS, a wolumen na dane użytkowników na Btrfs z kompresją i snapshotami.

Monitoring i diagnostyka: jak nie obudzić się z pełnym systemem plików

Niezależnie od wyboru systemu plików, prędzej czy później przychodzi dzień, gdy zaczyna brakować miejsca lub wydajność spada. Zamiast wtedy zgadywać, lepiej mieć wcześniej przygotowane podstawowe narzędzia i zwyczaje.

Dla wszystkich trzech systemów (ext4, XFS, Btrfs) przydatne są:

• iostat, vmstat, pidstat – do ogólnego oglądu, czy problem leży w I/O, CPU czy pamięci,
• iotop – szybki podgląd, który proces generuje największy ruch I/O,
• monitoring oparty o Prometheus/Zabbix + exporter dyskowy – alerty przy zapełnieniu przestrzeni czy rosnącym opóźnieniu I/O.

Specyficzne narzędzia dla poszczególnych systemów plików:

Jeśli chcesz pójść krok dalej, pomocny może być też wpis: Praktyczne użycie Wireshark w analizie sieci.

• ext4: fsck.ext4, tune2fs, dumpe2fs – do kontroli parametrów, sprawdzenia częstotliwości fsck, inspekcji superbloku.
• XFS: xfs_info, xfs_repair, xfs_growfs – informacje o strukturze, naprawa i rozszerzanie wolumenów.
• Btrfs: btrfs filesystem df, btrfs filesystem usage, btrfs balance, btrfs scrub – analiza zużycia, równoważenie danych, sprawdzanie integralności.

Dobrym nawykiem jest też ustawienie alertów na zapełnienie nie tylko całej partycji, ale i poszczególnych subwolumenów Btrfs, jeśli są intensywnie używane (np. katalogi backupowe). W przeciwnym razie system zgłosi „brak miejsca” w najmniej oczekiwanym momencie – oczywiście podczas wdrożenia.

Wydajność w praktyce: kiedy CoW pomaga, a kiedy przeszkadza

CoW w Btrfs i pewne cechy XFS (alokacja extentowa) potrafią pięknie pomóc przy typowych plikach użytkowników i logach, a jednocześnie mocno przeszkodzić przy bardzo specyficznych obciążeniach.

Kilka typowych sytuacji:

• Duże, rosnące logi – Btrfs z kompresją i domyślnym CoW sprawdza się całkiem dobrze, o ile nie mamy kilku ekstremalnie zapisywanych plików, które obrastają w miliony małych extentów. Jeśli logi są intensywne, warto rozważyć osobny subwolumen z lżejszą kompresją, a w ekstremum – wyłączenie CoW.
• VM-ki i obrazy dysków – przy częstych zapisach losowych do jednego dużego pliku CoW generuje fragmentację. Tu zwykle opłaca się katalog z obrazami oznaczyć jako nodatacow lub użyć ext4/XFS pod spód i Btrfs zostawić na inne dane.
• Snapshoty przy backupach – tworzenie snapshotu przed backupem (Btrfs, LVM, ZFS) sprawia, że backup widzi spójny obraz danych i nie blokuje aplikacji na czas kopiowania. To realny wzrost wydajności całego procesu – backup trwa swoje, ale system jest używalny.

Przy ocenie wydajności warto testować takie scenariusze, jakie faktycznie wystąpią na danej maszynie. Boniecie w dd i fio z prostym sekwencyjnym odczytem nie pokazują pełnej prawdy o tym, jak system plików zniesie np. połączenie małych losowych zapisów, snapshotów i kompresji.

Rozmiar bloków, inody i parametry formatowania

ext4 i XFS przy tworzeniu systemu plików oferują szereg parametrów, które mogą subtelnie (albo wcale) wpływać na wydajność. Mowa głównie o:

• rozmiarze bloku (zwykle 4K, aby pasował do strony pamięci),
• liczbie inode dla ext4 (gęstość inode odnosi się do maksymalnej liczby plików),
• parametrach alokacji grup i extentów.

Przy dzisiejszych rozmiarach dysków większość dystrybucji formatuje ext4 z bardzo rozsądnymi wartościami domyślnymi. Ręczna korekta ma sens głównie wtedy, gdy:

• z góry wiadomo, że system będzie przechowywał ogromną liczbę bardzo małych plików (np. maildir, cache),
• albo odwrotnie – głównie bardzo duże pliki (backupy, obrazy dysków),
• przygotowuje się system plików dla konkretnego sprzętu (np. macierze z nietypowym stripe size).

Btrfs ma nieco inne podejście: więcej logiki jest w samej warstwie alokacji i drzewach metadanych, mniej w ręcznym dobieraniu inode. Dzięki temu nie trzeba z góry decydować, ile plików się zmieści – inode są logiczne, nie „prealokowane” jak w ext4.

Integracja z narzędziami backupu i snapshotami systemowymi

System plików to tylko jedna z warstw. Prawdziwy komfort zaczyna się wtedy, gdy integruje się snapshoty i backupy z resztą narzędzi administracyjnych.

Typowe układy spotykane w praktyce:

• Btrfs + systemd / narzędzia distro – openSUSE, Fedora, niektóre warianty Ubuntu potrafią automatycznie tworzyć snapshoty przed instalacją aktualizacji (zypper, dnf, apt). Gdy aktualizacja pójdzie źle, można wrócić do poprzedniego stanu praktycznie w minutę.
• ext4/XFS + LVM snapshoty – klasyczne podejście: LVM pod spodem, system plików na wolumenie logicznym, a do backupów tworzone są snapshoty LVM. Mniej „sexy” niż Btrfs, ale bardzo przewidywalne i znane.
• Btrfs + narzędzia do backupów przyrostowych – borg, restic, Kopia dobrze się dogadują z Btrfs. Zwykle robi się snapshot, zamraża jego stan (readonly), a potem backup narzędziem wyższego poziomu, które robi własną deduplikację lub szyfrowanie.

Jeśli korzysta się z Btrfs, warto unikać dublowania roli snapshotów: nie ma sensu robić agresywnych snapshotów LVM pod spodem i jednocześnie snapshotów Btrfs na wierzchu. Jedna warstwa point-in-time zwykle w zupełności wystarcza, a dodatkowa tylko komplikuje odtwarzanie.

Bezpieczeństwo danych: od bit rot po przypadkowe „rm -rf”

Najprostszy scenariusz awarii danych to nie błąd dysku, tylko człowiek i jego ulubiona kombinacja klawiszy. Na tym polu snapshoty (LVM, Btrfs, ZFS) są często skuteczniejsze niż same RAID-y.

Dla porządku:

• RAID chroni głównie przed awarią sprzętu (padł dysk).
• Checksummy (Btrfs, ZFS) pomagają wykryć i naprawić ciche uszkodzenia sektora.
• Snapshoty chronią przed logiczną korupcją: błędnym skryptem, skasowaniem plików, nieudanym upgrade’em.
• Backup offline chroni przed tym wszystkim plus przed ransomware i „rm -rf” na nie tym serwerze, co trzeba.

Wybór systemu plików powinien więc wpisywać się w całą strategię ochrony danych. Użycie Btrfs z włączonymi checksumami i scrubem daje realną przewagę przy długim przechowywaniu danych, lecz nie zwalnia z robienia backupu na osobny serwer czy nośnik.

Mieszane środowiska: kiedy łączyć różne systemy plików

W wielu organizacjach kończy się z mieszanką: stare serwery na ext4, nowe zasoby na XFS, kilka maszyn testowych na Btrfs. To nie tylko naturalne, ale wręcz zdrowe podejście – narzędzia dobiera się do zadania, nie odwrotnie.

Kilka typowych konfiguracji, które działają bez dramatów:

• Hypervisor na XFS, storage maszyn na Btrfs – host KVM ma prosty, szybki system plików, a goście (np. VM-kowy NAS) korzystają z snapshotów i kompresji Btrfs u siebie.
• Serwer aplikacyjny: root na ext4, /data na Btrfs – prosty, przewidywalny system podstawowy, a elastyczny, snapshotowalny wolumen na dane aplikacji i pliki użytkowników.
• Serwer backupu: macierz hardware RAID + XFS/Btrfs – sprzętowy RAID zapewnia nadmiarowość i caching, a system plików trzyma porządek na poziomie plików; Btrfs dodatkowo daje snapshoty i checksummy.

Jedyny obszar, gdzie lepiej nie przesadzać z „kreatywnością”, to wielokrotne nakładanie warstw: mdraid na LVM na Btrfs z własnym RAID-em plus jeszcze thin provisioning. Da się, ale podczas awarii takie wieże Babel nie sprzyjają spokojowi ducha.

Automatyzacja i „polityka” systemu plików

Manualne zarządzanie snapshotami i scrubami jest w porządku na jednym-lub-dwóch serwerach. Przy większej liczbie maszyn opłaca się potraktować system plików jak element polityki konfiguracyjnej i zautomatyzować to, co się da.

Praktyczne przykłady automatyzacji:

• Jednolity zestaw timerów systemd dla Btrfs: okresowe scrub, snapshoty subwolumenów, czyszczenie starych migawek.
• Playbooki Ansible/puppet/chef, które:
  • tworzą subwolumeny i ustawiają dla nich konkretne opcje montowania,
  • zapewniają, że na serwerach bazodanowych CoW jest wyłączone w odpowiednich katalogach,
  • konfigurują monitoring pod konkretne punkty montowania i progi alarmowe.
• Skrypty utrzymaniowe, które przy większych zmianach (np. dodawanie dysku do puli Btrfs) wykonują serię komend razem z sanity checkami przed i po.

Taka „polityka systemu plików” sprawia, że nie ma dwóch serwerów skonfigurowanych „trochę inaczej, bo tak wyszło”. Przy awarii bardzo szybko okazuje się, jak cenne jest to nudne ujednolicenie.

Najczęściej zadawane pytania (FAQ)

Jaki system plików wybrać na Linuxa: ext4, XFS czy Btrfs?

Na zwykły desktop lub laptop wciąż najbezpieczniejszym i najbardziej przewidywalnym wyborem jest ext4. Dobrze działa z mieszanką małych i średnich plików, ma solidne narzędzia do naprawy (fsck, resize2fs) i jest domyślny w wielu dystrybucjach, więc o wsparcie nietrudno.

XFS sprawdza się lepiej tam, gdzie dominują duże pliki i wysokie sekwencyjne transfery – np. serwery plików, maszyny wirtualne, backupy. Btrfs z kolei jest sensownym wyborem, jeśli potrzebne są natywne snapshoty, kompresja, subwolumeny i elastyczne zarządzanie przestrzenią – typowo: domowy NAS, host kontenerów, system z prostym „cofnięciem się” po aktualizacji.

Czym praktycznie różni się ext4 od XFS i Btrfs?

Ext4 to „koń pociągowy”: prosty, stabilny, dobrze udokumentowany. Ma journaling, delayed allocation i extenty, ale nie oferuje natywnych snapshotów ani zaawansowanego zarządzania wolumenami. Sprawdza się tam, gdzie bardziej liczy się przewidywalność niż fajerwerki.

XFS projektowano pod duże systemy plików i wysokie obciążenia I/O. Lepiej radzi sobie z bardzo dużymi plikami i katalogami, ale odzyskiwanie danych po twardej awarii jest trudniejsze. Btrfs natomiast stosuje Copy-on-Write, ma snapshoty, kompresję, subwolumeny i integrację z RAID na poziomie systemu plików – za cenę większej złożoności i wrażliwości na błędy konfiguracji.

Jaki system plików jest najlepszy na serwer bazodanowy?

W typowych wdrożeniach produkcyjnych królują ext4 i XFS. Oba zapewniają niski latency i przewidywalne zachowanie przy intensywnym losowym I/O, co jest kluczowe dla baz danych. Ext4 bywa częściej wybierany tam, gdzie priorytetem jest łatwość naprawy i konserwatywne podejście, XFS – gdy pracujemy na dużych wolumenach i liczy się skalowalność.

Btrfs do baz danych nadaje się ostrożnie i raczej w scenariuszach, gdzie ważne są snapshoty do szybkich backupów/testów, a obciążenie nie jest skrajne. W środku krytycznego systemu finansowego lepiej nie robić z Btrfs pierwszego poligonu doświadczalnego.

Co wybrać na domowy NAS: ext4, XFS czy Btrfs?

Na prosty NAS do przechowywania filmów, zdjęć i backupów wystarczy ext4 lub XFS – szczególnie gdy NAS opiera się o klasyczny RAID kontrolera sprzętowego lub mdraid. Dla dużych, sekwencyjnych transferów (multimedia, kopie) XFS potrafi dać bardzo dobrą wydajność.

Jeżeli jednak ważne są snapshoty (np. do „cofania” przypadkowo usuniętych plików), kompresja i wbudowane mechanizmy ochrony przed cichą korupcją danych, Btrfs na NAS-ie pokazuje pazur. Trzeba tylko rzetelnie podejść do planowania RAID-u, scrubów i monitoringu, zamiast liczyć na „jakoś to będzie”.

Czy Btrfs jest już wystarczająco stabilny do codziennego użytku?

Do zastosowań desktopowych, domowych NAS-ów czy środowisk testowych – tak, Btrfs jest od lat używany w praktyce (część dystrybucji oferuje go jako domyślny system plików). Snapshoty root-a, szybkie rollbacki aktualizacji i kompresja dają realne korzyści w codziennym użytkowaniu.

W bardzo krytycznych systemach z mocno obciążonym I/O (ciężkie bazy, gigantyczne klastry) większość administratorów wciąż wybiera konserwatywnie ext4 lub XFS. Sam Btrfs nie jest już „eksperymentem”, ale wymaga większej świadomości konfiguracji niż „next, next, ext4”.

Jaki system plików będzie najlepszy pod kontenery (Docker, Kubernetes)?

Dla hostów kontenerowych interesujące są snapshoty, subwolumeny i efektywne zarządzanie setkami tysięcy małych plików. Btrfs dobrze wpisuje się w ten scenariusz dzięki Copy-on-Write, możliwości szybkiego klonowania warstw i granularnym snapshotom poszczególnych subwolumenów.

W praktyce nadal popularny jest ext4 na LVM lub RAID (z snapshotami na poziomie wolumenów), bo to rozwiązanie przewidywalne i dobrze znane. Jeśli jednak infrastruktura jest projektowana „od zera” pod kontenery i DevOps, Btrfs potrafi uprościć wiele czynności, które na ext4 wymagają dodatkowych narzędzi i warstw.

Czy wybór systemu plików ma duże znaczenie na SSD i NVMe?

Sam wybór systemu plików ma znaczenie, ale kluczowe są też szczegóły: poprawne wyrównanie partycji, użycie TRIM, opcje montowania i ewentualna kompresja. Nieprawidłowe alignment potrafi zabić wydajność nawet najlepszego NVMe, bo każdy logiczny zapis 4 KB kończy się dwoma fizycznymi zapisami.

Na SSD/NVMe często stosuje się ext4 lub XFS z noatime (mniej zbędnych zapisów), włączonym TRIM i rozsądnym rozmiarem bloków. Btrfs dodatkowo oferuje transparentną kompresję, która przy niektórych typach danych potrafi realnie zmniejszyć liczbę operacji zapisu i przedłużyć życie nośnika.