Journaling i system plików: ext4, btrfs, NTFS co wybrać pod wydajność

Dlaczego wybór systemu plików ma znaczenie dla wydajności

Kiedy system plików faktycznie ogranicza szybkość

System plików staje się wąskim gardłem, gdy aplikacje intensywnie pracują na dysku: zapisują tysiące małych plików, wykonują losowe odczyty, często synchronizują dane (fsync), utrzymują duże bazy danych lub wiele maszyn wirtualnych. W takich sytuacjach różnica między ext4, btrfs a NTFS bywa odczuwalna jako przycinki, opóźnione reakcje interfejsu, wysokie obciążenie I/O.

Przy lekkim, typowym użyciu desktopowym (przeglądarka, prosta edycja dokumentów, okazjonalne gry) różnice między ext4 a btrfs będą dla większości osób minimalne, o ile dysk jest w dobrej kondycji. System plików zaczyna grać pierwsze skrzypce, gdy sprzęt jest przeciążony lub profil I/O jest szczególnie wymagający.

Znaczenie rośnie także przy serwerach: plików, baz danych, CI/CD, wirtualizacji. Tam dowolne opóźnienie w dostępie do dysku mnoży się przez liczbę użytkowników lub usług, a zły wybór systemu plików i opcji montowania potrafi zepsuć nawet szybki serwer z dużą ilością RAM.

Wąskie gardła: CPU, RAM, dysk, sieć – jak je rozróżnić

Przed obwinieniem ext4, btrfs czy NTFS trzeba odróżnić, co tak naprawdę ogranicza wydajność. Pierwszym krokiem jest obserwacja obciążenia CPU, wykorzystania RAM i parametrów I/O.

Jeśli CPU pracuje stale na 90–100%, a I/O wait jest niski, problemem jest procesor lub aplikacja, nie system plików. Gdy RAM jest praktycznie pełny, a system zaczyna swapować, każdy system plików spowolni, bo dysk zastępuje pamięć. W takiej sytuacji parametry mount czy journaling niewiele pomogą – potrzeba więcej RAM lub innej architektury aplikacji.

System plików staje się głównym podejrzanym, gdy:

• obciążenie CPU jest umiarkowane, ale I/O wait (np. w top, htop) jest wysokie,
• aplikacje „zamierają” przy operacjach na plikach (zapis, otwieranie, listowanie katalogów),
• narzędzia typu iostat pokazują wysokie wykorzystanie dysku przy niewielkiej przepustowości.

Jeżeli dodatkowo sieć nie jest zapchana, a problem dotyczy tylko operacji dyskowych, warto przyjrzeć się systemowi plików, jego konfiguracji i journalingowi.

Typowe scenariusze użycia a znaczenie systemu plików

Na typowym laptopie z SSD, przeglądarką, edytorem kodu i kilkoma aplikacjami biurowymi, system plików ma znaczenie głównie dla czasu bootowania, szybkości startu aplikacji i ogólnej responsywności. W takich przypadkach ext4 z sensownymi opcjami montowania zwykle zapewnia „wystarczająco dobrą” wydajność, a zysk z btrfs pojawia się raczej w kontekście snapshotów i kompresji niż surowej szybkości.

Na serwerze plików, który serwuje duże pliki (backupy, multimedia), ważniejsza staje się przepustowość sekwencyjna, wydajność przy dużych katalogach oraz łatwość rozbudowy przestrzeni. Tutaj btrfs z kompresją i snapshotami może zmniejszyć obciążenie I/O i oszczędzić miejsce, ale kosztem większej złożoności administracyjnej.

W środowisku baz danych, kontenerów lub maszyn wirtualnych krytyczne jest I/O losowe, opóźnienia i przewidywalność zachowania w długim okresie. Dobrze skonfigurowany ext4 często wygrywa prostotą i stabilnością, natomiast btrfs wymaga starannego dobrania opcji, aby nie wpaść w problemy z fragmentacją i długimi operacjami konserwacyjnymi.

Journaling a wydajność i bezpieczeństwo danych

Na czym polega journaling i co jest logowane

Journaling to mechanizm zapisywania zmian w specjalnym dzienniku (journal), zanim zostaną one faktycznie zastosowane do struktury danych systemu plików. Celem jest ochrona spójności danych po awarii zasilania lub twardym resecie.

W praktyce większość systemów plików z journalingiem loguje przede wszystkim metadane, czyli informacje o strukturze plików i katalogów: inody, tablice alokacji, informacje o katalogach. Pełne logowanie danych użytkownika występuje w trybach o podwyższonym bezpieczeństwie, ale ma duży koszt wydajnościowy.

ext4 domyślnie loguje tylko metadane (tryb ordered), btrfs używa innego modelu opierającego się na copy-on-write (CoW), który również zapewnia spójność, ale bez klasycznego dziennika dla danych. NTFS prowadzi journaling metadanych, a niektóre operacje na danych są zabezpieczone mechanizmami transakcyjnymi na poziomie systemu.

Koszt dodatkowych zapisów na dysk

Journaling zwiększa liczbę operacji zapisu. Zmiana pliku może oznaczać zapis do dziennika, a potem właściwą modyfikację danych. Na HDD oznacza to dodatkowe ruchy głowicy i potencjalne spadki wydajności przy intensywnym I/O losowym.

Na SSD koszt jest inny: nie ma ruchomych części, ale zapis powoduje zużycie komórek pamięci i może wpływać na wear leveling. Dodatkowe zapisy z journalingu to większa liczba cykli zapisu, co ma znaczenie przy bardzo intensywnym użyciu (serwery baz danych, logowania na dużą skalę).

W zamian otrzymuje się dużo krótszy czas i większą przewidywalność naprawy po awarii. Zamiast długiego fsck skanującego cały wolumin, system odtwarza tylko niewielki, ostatni fragment journalu. Dla systemów produkcyjnych jest to często ważniejsze niż surowa wydajność w syntetycznych benchmarkach.

Tryby journalingu w ext4 i ich konsekwencje

ext4 udostępnia trzy główne tryby obsługi danych w kontekście journalingu:

• data=ordered – domyślny. Dane są zapisywane na dysk przed odnotowaniem w journalu metadanych. Daje niezłą ochronę przed zobaczeniem „śmieci” w pliku po awarii, przy akceptowalnym koszcie wydajnościowym.
• data=writeback – dane mogą zostać zapisane na dysk po odnotowaniu metadanych w journalu. Zwiększa wydajność, ale po awarii część pliku może zawierać stare lub nieprzewidywalne dane. Struktura systemu plików pozostaje spójna, ale zawartość plików może być uszkodzona.
• data=journal – zarówno dane, jak i metadane są zapisywane do journalu. Najbezpieczniejszy, ale też najwolniejszy tryb. Rzadko używany poza bardzo specyficznymi zastosowaniami, gdzie integralność danych jest ważniejsza niż wydajność.

Zmiana trybu journalingu to prosty sposób na przesunięcie balansu między bezpieczeństwem a szybkością. Na systemach testowych, tymczasowych lub maszynach developerskich tryb writeback bywa akceptowalny. Na serwerach produkcyjnych zwykle pozostaje się przy ordered.

Journaling a odporność na awarie zasilania

Bez journalingu awaria prądu może pozostawić system plików w stanie niespójnym: część struktur jest już zaktualizowana, a część nie. Przy starannie skonfigurowanym journalingu skutki awarii ograniczają się zwykle do ostatnich niezapisanych operacji, a naprawa jest szybka.

ext4 z domyślnym journalingiem metadanych zapewnia bardzo dobrą odporność na typowe awarie. btrfs, dzięki copy-on-write, zapisuje zmiany w nowych lokalizacjach i dopiero na końcu „przełącza” wskaźniki, co również chroni przed częściowo zapisanymi strukturami. NTFS w środowisku Windows jest mocno zintegrowany z mechanizmami odzyskiwania po awarii i w praktyce radzi sobie dobrze, o ile sprzęt nie ma wad.

Redukowanie bezpieczeństwa (np. wyłączenie journalingu, agresywne ustawienia data=writeback, wyłączone bariery zapisu) dla kilku procent wydajności zwykle opłaca się tylko na testowych maszynach lub w bardzo specyficznych zastosowaniach, gdzie dane są łatwe do odtworzenia.

Sprzęt a wybór systemu plików: SSD, HDD, RAID

SSD kontra HDD – różnice w profilu I/O

HDD ma dobre osiągi przy sekwencyjnym odczycie i zapisie, ale dramatycznie słabnie przy I/O losowym. Duża liczba małych, rozrzuconych zapisów i odczytów powoduje ciągłe ruchy głowicy, wysokie opóźnienia i spadek przepustowości.

SSD ma znacznie niższe opóźnienia, świetnie radzi sobie z I/O losowym i oferuje wysoką liczbę operacji IOPS. Problemem jest za to ograniczona liczba cykli zapisu na komórkę i wewnętrzna złożoność kontrolera, który musi równoważyć zużycie (wear leveling) i zarządzać blokami.

System plików na HDD powinien minimalizować fragmentację, unikać nadmiernej liczby małych zapisów w losowych miejscach i dobrze radzić sobie z dużymi plikami. Na SSD większe znaczenie ma ograniczenie niepotrzebnych zapisów (noatime, rozsądny journaling) oraz korzystanie z funkcji typu TRIM.

System plików a SSD: TRIM, alignment, write amplification

TRIM pozwala systemowi plików informować SSD, które bloki są już nieużywane. Dzięki temu kontroler może lepiej zarządzać wolną przestrzenią, ograniczyć write amplification i utrzymać wysoką wydajność w długim okresie.

ext4 i btrfs obsługują TRIM. Można go wywoływać okresowo komendą fstrim (np. przez systemd-timer) albo włączyć tryb ciągły discard w opcjach montowania. Tryb ciągły zmniejsza opóźnienie uwalniania bloków, ale generuje dodatkowe operacje w tle.

Alignment, czyli wyrównanie partycji do bloków fizycznych SSD (zwykle 1 MiB), ma duże znaczenie dla wydajności. Nowoczesne narzędzia (parted, gparted) domyślnie tworzą poprawnie wyrównane partycje, ale przy starszych schematach (MBR, ręczne manipulacje) warto to sprawdzić.

RAID programowy, sprzętowy i btrfs RAID

RAID wprowadza dodatkową warstwę między systemem plików a fizycznymi dyskami. RAID sprzętowy prezentuje pojedynczy logiczny dysk, a system plików widzi go jak jeden nośnik. RAID programowy (mdadm) działa w jądrze i również udostępnia logiczne urządzenie blokowe.

btrfs potrafi sam zarządzać RAID-em na poziomie systemu plików (mirror, RAID1, RAID10, RAID5/6 – te ostatnie nadal z zastrzeżeniami). Daje to zaawansowane możliwości: elastyczne dodawanie dysków, balansowanie, sprawdzanie sum kontrolnych na poziomie bloków danych.

Przykładowo mały serwer z jednym SSD i jednym HDD może użyć ext4 na SSD dla systemu i VM, a btrfs na HDD w trybie single lub mirror dla backupów i snapshotów. Z kolei macierz wielu HDD pod backup, gdzie liczy się przepustowość sekwencyjna i snapshoty, może skorzystać z btrfs RAID1/10, o ile administrator akceptuje jego specyfikę i śledzi stan projektu.

ext4 – stabilna baza pod wydajność

Charakterystyka i dojrzałość ext4

ext4 to domyślny system plików w wielu dystrybucjach Linuksa od lat. Jest stabilny, dobrze przetestowany na szerokiej gamie sprzętu i przewidywalny pod względem wydajności. Brakuje mu części nowoczesnych funkcji (snapshoty, kompresja, wbudowany RAID), ale w zamian jest prosty w administracji.

Jego zachowanie w różnych scenariuszach jest dobrze znane. Wycieki pamięci, trudne do zdiagnozowania błędy czy regresje wydajności pojawiają się rzadko i zwykle szybko są naprawiane. To jeden z powodów, dla których na serwerach produkcyjnych ext4 pozostaje bezpiecznym wyborem.

Pod względem wydajności ext4 oferuje dobrą równowagę między szybkością sekwencyjną, obsługą małych plików i odpornością na awarie. Na SSD spisuje się bardzo dobrze, szczególnie z ograniczonym journalingiem i sensownymi opcjami montowania.

Mechanizmy poprawiające wydajność ext4

ext4 wprowadza szereg rozwiązań wydajnościowych:

• Extents – zamiast przechowywać każdy blok pliku osobno, ext4 pracuje na zakresach bloków. Zmniejsza to fragmentację i przyspiesza operacje na dużych plikach.
• Delayed allocation – opóźnione przydzielanie bloków wymaga mniej zapisów i umożliwia lepszą optymalizację rozmieszczenia danych. To szczególnie korzystne przy sekwencyjnych zapisach.
• Journaling z trybem ordered – sensowny kompromis między bezpieczeństwem a wydajnością, zwykle wystarczający dla desktopów i wielu serwerów.
• Barriers – zabezpieczają przed utratą danych z buforów dysku przy awarii zasilania, kosztem niewielkiego spowolnienia; przy zasilaczach UPS i kontrolerach z BBU można rozważyć ich wyłączenie, ale wymaga to świadomości ryzyka.

Opcje takie jak journal_async_commit i odpowiednio dobrany interwał commit= pozwalają dopasować częstotliwość zapisów journalu, co wpływa zarówno na wydajność, jak i ryzyko utraty ostatnich sekund zmian.

Gdzie ext4 jest „wystarczająco szybki”

ext4 bardzo dobrze sprawdza się jako system plików dla:

• typowych desktopów i laptopów z SSD lub HDD,
• serwerów aplikacyjnych z umiarkowanym I/O,
• hostów maszyn wirtualnych (KVM, VirtualBox), gdzie obrazy VM to duże pliki,
• serwerów baz danych, o ile zadbana jest konfiguracja fsync, cache i parametry journalingu.

Kiedy ext4 zaczyna być ograniczeniem

ext4 ma swoje granice. Przy setkach tysięcy plików w jednym katalogu narzut na wyszukiwanie i operacje metadanych rośnie. Działa to, ale latency skacze i różne narzędzia użytkowe (backup, skanery) zaczynają się dusić.

Przy intensywnych obciążeniach typu CI/CD, gdzie dziennie powstają ogromne ilości małych plików, ext4 daje radę, ale defragmentacja katalogów i rosnący czas stat() potrafią być odczuwalne. W takich sytuacjach btrfs z subwolumenami lub inny model podziału danych bywa praktyczniejszy.

Druga grupa problemów to zaawansowane scenariusze storage: snapshoty per kontener, replikacja block-level, partycjonowanie przestrzeni pomiędzy wielu najemców. ext4 tego po prostu nie ma – trzeba dokładać warstwy typu LVM, ZFS lub narzędzia wirtualizacji.

btrfs – funkcje a koszt wydajności

Copy-on-write i jego wpływ na szybkość

btrfs jest systemem plików copy-on-write. Każda modyfikacja bloku oznacza zapisanie go w nowe miejsce i późniejsze „przepięcie” wskaźników. To ogromna zaleta przy snapshotach i spójności danych, ale wprowadza narzut przy intensywnych zapisach.

Przy sekwencyjnym zapisie dużych plików btrfs bywa zbliżony do ext4, szczególnie na SSD. Przy częstych nadpisaniach niewielkich fragmentów (bazy danych, logi, VM) włącza się efekt fragmentacji i write amplification, co potrafi mocno obniżyć throughput i podnieść latency.

Dobrym kompromisem jest trzymanie wrażliwych na COW danych (np. katalog z bazą) na podwolumenie zamontowanym z opcją nodatacow lub z atrybutem chattr +C ustawionym przed utworzeniem plików. Wtedy te konkretne pliki zachowują się bardziej jak na klasycznym FS.

Snapshoty, subwolumeny i codzienna praca

Snapshoty w btrfs są lekkie i szybkie. Wykonanie snapshotu subwolumenu jest praktycznie natychmiastowe, bo polega na skopiowaniu wskaźników, a nie danych. Koszt pojawia się później – przy modyfikacjach, które zaczynają duplikować bloki.

Przy sensownym harmonogramie snapshotów (np. kilka dziennych, rotacja tygodniowa) overhead jest często akceptowalny, a zysk administracyjny ogromny. Problem zaczyna się przy dziesiątkach snapshotów utrzymywanych miesiącami, bo fragmentacja rośnie, a operacje typu balance i delete snapshot potrafią zjadać I/O przez długi czas.

Subwolumeny pomagają logicznie rozdzielić obszary o różnych potrzebach wydajnościowych. System i /var/log mogą korzystać z COW i snapshotów, a katalog z maszynami wirtualnymi działać bez COW i z innymi opcjami montowania.

Kompresja transparentna – kiedy się opłaca

btrfs oferuje kompresję transparentną (zstd, lzo). Z punktu widzenia wydajności są trzy scenariusze:

• dużo tekstu/logów – kompresja zmniejsza ilość I/O, często przyspiesza odczyt, CPU zwykle nie jest wąskim gardłem,
• multimedia, archiwa – zysk znikomy, w niektórych przypadkach narzut na CPU i metadata,
• mieszane workloady – zysk zależy od proporcji typów danych i możliwości CPU.

Na współczesnych serwerach z zapasem CPU compress=zstd z umiarkowanym poziomem kompresji bywa sensowny jako domyślny. Na słabszych maszynach, zwłaszcza z HDD i intensywnym I/O, opłaca się test A/B na realnym workloadzie.

Fragmentacja i utrzymanie btrfs

Copy-on-write naturalnie prowadzi do większej fragmentacji niż w ext4, zwłaszcza przy mieszanym obciążeniu i snapshotach. btrfs udostępnia narzędzia typu btrfs filesystem defragment oraz operacje balance, które realnie wpływają na wydajność.

Defragmentacja jest przydatna dla katalogów z VM, dużych plików baz danych czy repozytoriów, gdzie modyfikacje są częste i nieciągłe. balance natomiast pomaga wyrównać rozłożenie extentów i metadanych po dużych zmianach w topologii dysków lub po masowych usunięciach danych.

Obie operacje obciążają I/O, więc dobrze je planować na okresy mniejszego ruchu. Zaniedbany btrfs po latach intensywnego użycia potrafi działać wyraźnie wolniej niż świeży, mimo że teoretycznie ma jeszcze dużo wolnego miejsca.

Scenariusze, w których btrfs ma przewagę

btrfs jest sensownym wyborem tam, gdzie integracja funkcji jest ważniejsza niż absolutne maksimum wydajności:

• stacje developerskie z intensywnym użyciem kontenerów i snapshotów systemu,
• serwery plików, gdzie snapshoty per udział i kompresja dają wymierny zysk,
• małe i średnie serwery z kilkoma dyskami, gdzie btrfs RAID1/10 upraszcza zarządzanie.

Przy bazach danych typu PostgreSQL/MySQL na btrfs zwykle stosuje się nodatacow dla katalogu danych, rezygnując z części zalet btrfs w zamian za stabilną wydajność pod intensywnym zapisem.

NTFS – wydajność natywna i w świecie Linuksa

Charakterystyka NTFS w Windows

NTFS został zaprojektowany z myślą o Windows, dużych woluminach i rozbudowanych ACL. W natywnym środowisku pracuje blisko jądra systemu, ma własne mechanizmy cache i journaling ściśle powiązany z kernelowym I/O.

W typowych desktopowych scenariuszach NTFS jest wystarczająco szybki i przewidywalny. Windows agresywnie buforuje operacje, a narzędzia systemowe (defrag, chkdsk) są zoptymalizowane specjalnie pod ten FS.

Problemy z wydajnością pojawiają się najczęściej przy wielu małych plikach na wolnych HDD, podobnie jak w ext4, oraz przy długotrwale zaniedbanej fragmentacji, choć współczesne wersje Windows robią defragmentację i optymalizacje w tle.

NTFS na Linuksie: ntfs-3g kontra ntfs3

Na Linuksie NTFS to inna historia. Przez lata standardem był sterownik ntfs-3g w przestrzeni użytkownika (FUSE). Oferował dobrą zgodność, ale ograniczoną wydajność, zwłaszcza przy intensywnym I/O i małych operacjach.

Nowy sterownik ntfs3 działa w jądrze, co znacząco poprawia szybkość. W nowoczesnych dystrybucjach jest już dostępny i w wielu przypadkach jest domyślny. Dla dysków współdzielonych z Windows, które wymagają zapisu, ntfs3 to praktycznie jedyny sensowny wybór.

Mimo poprawy nadal jest to FS „gościnny”: rozwój i testy nie są tak szerokie jak dla ext4 czy btrfs. Do obciążeń serwerowych czy intensywnego I/O na Linuksie lepiej formatować dyski natywnie jako ext4/btrfs i używać NTFS tylko tam, gdzie wymaga tego interoperacyjność z Windows.

Mount options NTFS pod Linuksem a wydajność

Przy montowaniu NTFS na Linuksie kilka opcji ma wpływ na szybkość:

• uid, gid, umask – statyczne mapowanie uprawnień, mniej narzutu przy każdej operacji plikowej,
• noatime – klasycznie zmniejsza liczbę zapisów,
• big_writes (w ntfs-3g) – zwiększa rozmiar buforowanych zapisów, co poprawia throughput sekwencyjny.

NTFS na Linuksie nadaje się dobrze do dysków przenośnych, archiwów wymienianych z Windows, ale nie jako FS pod katalogi /var, /home w środowisku stricte linuksowym, gdzie zależy na latency i przewidywalności.

Porównanie wydajności ext4, btrfs i NTFS w praktyce

Desktop, gry, typowe aplikacje

Na komputerze domowym z Linuksem ext4 na SSD wciąż jest najprostszym i najstabilniejszym wyborem. Szybki start systemu, niskie opóźnienia, dobre zachowanie pod obciążeniem mieszanym.

btrfs daje dodatkowo snapshoty systemu i kompresję. Przy grach i dużych plikach różnica w FPS czy czasach ładowania jest zwykle niewielka, o ile SSD jest szybki. Korzyść z btrfs to raczej łatwe cofanie zmian po nieudanej aktualizacji niż surowa wydajność.

NTFS pojawia się tu głównie przy dual boocie z Windows. Dane współdzielone (np. katalog z grami na osobnym dysku) mogą leżeć na NTFS, ale dostęp z Linuksa przez ntfs3 zawsze będzie odrobinę gorszy niż natywnie na Windows.

Serwery plików i backup

Serwery plików obsługujące SMB/NFS mają inne priorytety: spójność, snapshoty, replikacja. ext4 zapewnia dobrą wydajność i prostotę, ale snapshoty trzeba realizować zewnętrznie (LVM, ZFS, filesystem-level backup).

btrfs błyszczy przy backupach: snapshoty przyrostowe, kompresja, subwolumeny per klient lub udział. Koszt to większa złożoność oraz konieczność monitorowania stanu (RAID5/6, balansowanie). Na HDD różnice w wydajności sekwencyjnej względem ext4 są często akceptowalne, szczególnie przy backupach nocnych.

NTFS jako FS pod serwer Samba na Linuksie nie ma sensu – lepiej używać ext4/btrfs i udostępniać je po SMB. NTFS powinien pojawiać się raczej po stronie Windows, a nie jako backend na Linuksie.

Bazy danych i systemy transakcyjne

Bazy danych mocno obnażają cechy systemu plików. Dla Postgresa, MySQL i podobnych najważniejsze są: stabilne fsync, niskie opóźnienia zapisów losowych i przewidywalne flushowanie cache.

ext4 jest tutaj sprawdzonym wyborem. Przy rozsądnym data=ordered, włączonych barierach i dobrze ustawionych parametrach jądra (dirty_ratio, elevator) daje powtarzalne wyniki. Większość poradników optymalizacji baz danych na Linuksa powstawała właśnie na ext4.

btrfs wymaga ostrożności: katalog danych bazy zwykle montuje się z nodatacow, noatime, często z wyłączoną kompresją. Wtedy zachowuje się podobnie do klasycznego FS, kosztem utraty snapshotów na poziomie bloków. Zaleta btrfs w tym kontekście to raczej snapshoty logów i systemu niż sam katalog danych.

NTFS w Windows działa dobrze z SQL Server, Postgres czy MySQL, ale tam liczy się cały stos: scheduler I/O, write cache, konfiguracja sterowników dyskowych. Przenoszenie tych ustawień „wprost” na Linuksa zwykle nie ma sensu – to inny ekosystem.

Maszyny wirtualne i kontenery

Przy maszynach wirtualnych typowy wzorzec to kilka dużych plików z intensywnym I/O losowym wewnątrz. ext4 radzi sobie z tym dobrze, szczególnie na SSD, ale warto zadbać o noatime i rozsądny rozmiar bloków.

btrfs pozwala robić snapshoty VM w locie, co jest sporą przewagą operacyjną. Jednak COW na duże pliki VM powoduje fragmentację. Najczęściej katalog z VM montuje się z nodatacow, snapshoty robi na poziomie hypervisora (qcow2, LVM), a btrfs wykorzystuje do snapshotów systemu gospodarza i danych aplikacyjnych.

Kontenery (Docker, Podman) korzystają z warstwowych systemów plików. Na btrfs snapshoty warstw i obrazów są bardzo szybkie i lekkie. ext4 działa dobrze, ale wymaga backendów typu overlayfs, które mają własne ograniczenia wydajnościowe przy głębokich drzewach warstw.

Opcje montowania wpływające na wydajność

Ogólne opcje: atime, bariery, rozmiary bloków

Niezależnie od systemu plików, kilka opcji montowania powtarza się w kontekście wydajności:

• noatime / nodiratime – wyłącza aktualizację czasu dostępu; znacząco zmniejsza liczbę zapisów dla workloadów z częstym odczytem,
• barrier / nobarrier (lub odpowiedniki) – kontrola flushowania buforów dysku; nobarrier przyspiesza, ale ryzykuje utratę danych przy awarii zasilania bez BBU/UPS,
• block size – zwykle 4K, zbieżne z rozmiarem strony pamięci; zmiana ma sens tylko w specyficznych scenariuszach i powinna być poprzedzona testami.

Na SSD i w środowiskach z dużą ilością odczytów noatime jest dzisiaj niemal standardem. Z kolei nobarrier ma sens głównie w serwerowniach z porządnym zasilaniem awaryjnym i kontrolerami RAID z własnym buforem bateryjnym.

ext4 – najczęściej używane opcje

ext4 pozwala sporo dostroić. Kilka opcji ma szczególnie duży wpływ na praktyczną wydajność:

• data=ordered/writeback/journal – omówione wcześniej, główny dźwignik balansujący bezpieczeństwo/zapis,
• commit=N – okres w sekundach między wymuszeniami zapisu journalu; większa wartość => mniej zapisów, więcej danych ryzykowanych przy awarii,
• journal_async_commit – asynchroniczne commitowanie journalu, poprawa throughputu kosztem możliwości utraty kilku ostatnich sekund danych,
• inode_readahead_blks – prefetch inodów, może pomagać przy skanowaniu dużych drzew katalogów.

btrfs – opcje montowania a koszt COW

btrfs ma więcej przełączników, ale kilka z nich decyduje o tym, czy system „zamuli” pod zapisem, czy będzie działał przewidywalnie.

• compress=zstd/lzo – kompresja transparentna; na szybkich CPU i wolniejszych dyskach często poprawia odczyt/zapis sekwencyjny (mniej danych do przeniesienia), ale potrafi dodać latencję przy losowym I/O,
• nodatacow – wyłącza COW dla danych istniejących plików na danym subwolumenie lub katalogu (przy chattr +C); kluczowe dla katalogów baz danych, VM i dużych repozytoriów,
• ssd / ssd_spread – hint dla sterownika, jak rozkładać dane na SSD; zwykle ssd wystarcza, ssd_spread przydaje się na starszych lub „dziwnych” SSD,
• space_cache=v2 – nowszy mechanizm cache wolnej przestrzeni; przyspiesza alokacje i operacje na wielu małych plikach,
• autodefrag – defragmentacja w locie małych, często modyfikowanych plików; pomaga przy plikach konfiguracyjnych, logach, ale może szkodzić przy dużych plikach VM.

Typowy serwer backupu na btrfs: globalnie compress=zstd,space_cache=v2,ssd, a katalogi z dużymi plikami VM oznaczone chattr +C i podmontowane z nodatacow. Snapshoty robi się na poziomie subwolumenów backupu, a nie samych obrazów VM.

NTFS – praktyczne strojenie pod kątem I/O

W Windows większość „tuningu” NTFS to w zasadzie strojenie cachowania systemu i harmonogramu zadań w tle, a nie samego FS.

• Write caching w ustawieniach urządzenia – włączenie daje lepszy throughput, ale bez UPS lub baterii w laptopie ryzyko utraty ostatnich zapisów rośnie,
• Wyłączenie indeksowania (Windows Search) dla wolumenów z dużą liczbą małych plików roboczych – mniej losowego I/O w tle,
• Wyłączenie automatycznej defragmentacji tylko tam, gdzie używane są pliki VHDX/VM lub specyficzne aplikacje, które same zarządzają layoutem; zwykle lepiej zostawić domyślne ustawienia.

Na Linuksie z ntfs3 poza opcjami montowania sens ma ustawienie odpowiedniego I/O scheduler (mq-deadline, none na NVMe) i ograniczenie intensywnego I/O na NTFS tylko do scenariuszy wymiany danych z Windows.

Proste testy wydajności systemów plików

Przygotowanie środowiska do testów

Żeby porównanie miało sens, trzeba zadbać o kilka podstawowych rzeczy.

• Testuj na czystym, świeżo utworzonym systemie plików lub po pełnym trim na SSD.
• Wyłącz inne intensywne procesy I/O (backupy, indeksowanie, kontenery).
• Sprawdź, czy nie działają procesy typu updatedb, balooning hypervisora, cronowe rotacje logów.
• Notuj wersję jądra, sterowników, firmware dysku i dokładne opcje montowania.

W praktyce sensowne jest zrobienie osobnej, tymczasowej partycji tylko do testów, żeby nie mieszać danych produkcyjnych z plikami generowanymi przez benchmarki.

fio – elastyczne testy sekwencyjne i losowe

fio to podstawowe narzędzie, gdy trzeba naśladować konkretny profil obciążenia.

Przykładowy test odczytu/zapisu sekwencyjnego dla dużego pliku:

fio --name=seq_rw --directory=/mnt/test 
  --size=4G --bs=1M --rw=readwrite --iodepth=16 
  --direct=1 --numjobs=1 --time_based --runtime=60

Parametry istotne przy porównaniu FS, a nie samego dysku:

• –directory – ten sam punkt montowania / ten sam dysk, różne FS,
• –direct=1 – omija cache strony, testuje ścieżkę bezpośrednią; do porównania zachowania FS ma to sens, choć nie odzwierciedla pełni „user experience”,
• –rw – randread, randwrite, randrw do symulacji baz danych czy VM.

Przykład prostego testu losowego zapisu małych bloków (profil zbliżony do bazy danych):

fio --name=rand_db --directory=/mnt/test 
  --size=2G --bs=4k --rw=randwrite --iodepth=32 
  --direct=1 --numjobs=4 --time_based --runtime=120

Dla porównania ext4 vs btrfs vs NTFS (ntfs3) można użyć tych samych jobów i skupić się na IOPS oraz średniej latencji, nie tylko na MB/s.

bonnie++ i iozone – szybkie spojrzenie „z góry”

Dwa stare, ale wciąż przydatne narzędzia do ogólnego porównania.

bonnie++ skupia się na:

• sekwencyjnym odczycie/zapisie,
• operacjach na metadanych (tworzenie, odczyt, usuwanie plików),
• wydajności przy małych plikach.

Przykład:

bonnie++ -d /mnt/test -s 4G -r 0 -n 100000:0:0:0

iozone pozwala szybko sprawdzić różne rozmiary bloków i patterny:

iozone -a -g 4G -i 0 -i 1 -i 2 -f /mnt/test/iozone.tmp

Do poważnych decyzji produkcyjnych lepiej użyć fio z profilem zbliżonym do realnego obciążenia, ale bonnie++/iozone dobrze pokazują, czy np. btrfs mocno nie odstaje przy małych plikach na danym sprzęcie.

Testowanie opóźnień i zachowania pod mieszanym obciążeniem

Same testy sekwencyjnego throughputu nie pokazują, jak FS zachowuje się w warunkach „życia codziennego”.

Przykładowy scenariusz:

• jedno fio generuje sekwencyjny zapis backupu (duże bloki, rw=write),
• drugie fio w tym samym czasie generuje losowe odczyty (rw=randread) małych bloków na innym pliku.

Na część FS (szczególnie COW jak btrfs bez nodatacow) wpływa to wyraźnie: backup schodzi szybciej, ale rośnie latencja dla zastosowań interaktywnych. ext4 zwykle radzi sobie stabilniej, choć też potrafi „przydusić” desktop, jeśli brak jest sensownego I/O schedulera.

Monitorowanie podczas testów: iostat, pidstat, btrfs stats

SAME wyniki z fio niewiele mówią, jeśli nie widać, co dzieje się w tle.

• iostat -x 1 – pokazuje obciążenie pojedynczych urządzeń (util, svctm, await),
• pidstat -d 1 – śledzi procesy generujące I/O,
• btrfs filesystem df / btrfs filesystem usage – pokazują rozkład alokacji na btrfs, mogą ujawnić nadmierną fragmentację lub nieoczekiwane zużycie metadanych.

Dla ext4 przydatne bywa też dumpe2fs -h, żeby potwierdzić ustawienia journalu, rozmiar bloków i włączenie funkcji typu haszowane katalogi (dir_index).

Interpretacja wyników pod kątem realnego zastosowania

Przy porównaniu FS łatwo „zachwycić się” kilkuprocentową różnicą w MB/s, która w codziennym użyciu jest niewidoczna.

Kilka praktycznych zasad:

• dla desktopu / gier ważniejsze są czasy dostępu (latencja) i zachowanie pod mieszanym obciążeniem niż absolutny throughput sekwencyjny,
• dla baz danych kluczowe są IOPS i stabilność opóźnień przy losowym I/O, nie maksymalne MB/s,
• dla backupów nocnych liczy się głównie sekwencyjny zapis i koszt miejsca (kompresja, deduplikacja, snapshoty),
• dla VM – jak rośnie fragmentacja i jak spada wydajność po tygodniach intensywnego użycia.

Sensowne podejście: najpierw określić profil obciążenia (np. „80% małe losowe zapisy, 20% sekwencyjne odczyty”), potem zbudować na jego podstawie joby dla fio i dopiero na końcu sprawdzić, który FS lepiej się w tym odnajduje na konkretnym sprzęcie.

Krótki przykład praktyczny

Serwer z dwoma SSD, na których ma działać Postgres i backupy. Na jednym SSD tworzony jest ext4 z data=ordered,noatime,commit=10 pod katalog danych bazy. Na drugim – btrfs z compress=zstd,space_cache=v2,noatime pod snapshoty backupów i pliki archiwalne.

Test fio z losowym I/O 4K pokazuje, że ext4 na pierwszym SSD daje niższą i stabilniejszą latencję przy zapisie, btrfs lekko odstaje, ale winą jest głównie COW. Dla backupów różnica znika, za to kompresja na btrfs realnie zmniejsza ilość miejsca o kilkadziesiąt procent. Na tej podstawie katalog danych bazy zostaje na ext4, a backupy i snapshoty rotowane są na btrfs.

Najczęściej zadawane pytania (FAQ)

ext4 czy btrfs – co wybrać pod wydajność na desktopie?

Na typowym laptopie lub PC z SSD, przy przeglądarce, IDE i biurowych aplikacjach, ext4 zwykle jest wystarczająco szybki i prosty w utrzymaniu. Daje przewidywalną wydajność, krótkie czasy startu systemu i aplikacji.

btrfs ma sens, gdy chcesz korzystać ze snapshotów, kompresji czy łatwej rozbudowy przestrzeni. Pod względem „surowej” szybkości w typowym scenariuszu różnice względem ext4 są małe, ale btrfs wymaga więcej uwagi (opcji montowania, kontroli fragmentacji).

Jaki system plików pod bazy danych, kontenery i maszyny wirtualne?

Przy intensywnym I/O losowym (bazy danych, VM-ki, kontenery) liczą się opóźnienia i przewidywalność. Tutaj najczęściej wybiera się ext4 z dobrze dobranymi opcjami montowania, bo jest stabilny i ma niskie narzuty.

btrfs da się skonfigurować pod takie obciążenia, ale łatwiej „przestrzelić się” z ustawieniami i skończyć z fragmentacją oraz długimi operacjami konserwacyjnymi. Jeśli priorytetem jest spokój i stała wydajność, ext4 będzie bezpieczniejszym wyborem.

Czy journaling spowalnia dysk SSD?

Journaling generuje dodatkowe zapisy, więc teoretycznie obniża wydajność i zwiększa zużycie komórek flash. Na współczesnym SSD z normalnym, biurowo-programistycznym profilem użycia różnica jest jednak niewielka i na ogół niewyczuwalna.

Strata kilku procent w syntetycznych benchmarkach jest ceną za dużo szybsze i przewidywalne odzyskanie systemu po awarii zasilania. Praktycznie ma to znaczenie dopiero przy bardzo intensywnych serwerowych obciążeniach zapisem.

Jaki tryb journalingu ext4 jest najszybszy i czy warto go używać?

Najszybszy jest tryb data=writeback, bo pozwala zapisywać dane na dysk po odnotowaniu metadanych w journalu. Zwiększa to wydajność, ale po awarii część pliku może zawierać stare lub nieprzewidywalne dane.

Na systemach produkcyjnych zwykle zostaje się przy domyślnym data=ordered, który dobrze balansuje bezpieczeństwo i szybkość. data=writeback ma sens na maszynach testowych, tymczasowych lub tam, gdzie dane można łatwo odtworzyć.

Po czym poznać, że to system plików jest wąskim gardłem, a nie CPU lub RAM?

Objawami problemów z I/O są m.in. umiarkowane użycie CPU przy wysokim I/O wait (w top/htop), „zawieszanie się” aplikacji przy operacjach na plikach oraz wysokie wykorzystanie dysku w iostat przy względnie niskiej przepustowości.

Jeśli CPU stale pracuje na 90–100% przy niskim I/O wait, wąskim gardłem jest procesor lub sama aplikacja. Gdy RAM jest prawie pełny i system intensywnie swapuje, każdy system plików zwolni – rozwiązaniem jest więcej pamięci lub zmiana architektury.

ext4 czy NTFS – co lepsze pod wydajność w Linuxie i Windows?

W Windows natywnym systemem plików jest NTFS i tam działa on najlepiej. Pod Linuksem ext4 jest zoptymalizowany i wspierany bezpośrednio w kernelu, więc zwykle będzie szybszy i stabilniejszy niż NTFS montowany przez warstwę zgodności.

Do współdzielenia danych między Linuxem a Windowsem lepiej użyć osobnej partycji z exFAT lub NTFS tylko na dane, ale system operacyjny trzymać na ext4 (Linux) i NTFS (Windows).

Czy na HDD lepiej wyłączyć journaling, żeby przyspieszyć dysk?

Wyłączenie journalingu faktycznie zmniejsza liczbę zapisów i może nieco poprawić wydajność na dyskach talerzowych przy intensywnym I/O. Jednocześnie bardzo podnosi ryzyko uszkodzenia systemu plików po twardym resecie lub zaniku zasilania.

Na HDD w środowiskach produkcyjnych lepiej zostać przy journalingu i ewentualnie optymalizować inne elementy (kolejność I/O, ustawienia aplikacji, RAM). Wyłączenie journalingu ma sens głównie na tymczasowych, mało istotnych wolumenach.

Bibliografia i źródła

• Understanding the Linux Virtual Memory Manager. Prentice Hall (2004) – Opis interakcji I/O, pamięci, CPU i wpływu na wydajność systemu plików
• Linux Kernel Documentation: Filesystems (ext4). The Linux Kernel Documentation Project – Oficjalne informacje o ext4, journalingu i trybach data=ordered/writeback/journal
• Btrfs: The Linux B-tree Filesystem. Oracle – Architektura btrfs, copy-on-write, snapshoty i implikacje wydajnościowe
• NTFS Technical Reference. Microsoft – Opis wewnętrznej struktury NTFS, journalingu metadanych i transakcyjności
• Linux Performance Tuning Guidelines. Red Hat – Praktyczne wskazówki dot. I/O, wąskich gardeł CPU/RAM/dysk i doboru systemu plików
• Storage Performance Development Kit (SPDK) Documentation. Intel – Charakterystyka wydajności SSD vs HDD, wpływ losowego i sekwencyjnego I/O