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 p