Wydanie Linux 7.4-rc1 przechodzi do historii z rekordową liczbą 19 671 zmian zintegrowanych w oknie scalania, deklasując poprzedni szczyt 16 267 modyfikacji z wersji 7.3. Dla inżynierów systemowych i administratorów nie jest to wyłącznie statystyczna anomalia. To namacalny dowód na ewolucję w sposobie audytowania jądra oraz moment, w którym ext4 – system plików napędzający miliony serwerów – wykonuje potężny skok architektoniczny, próbując ostatecznie odciąć się od przestarzałych struktur VFS.
Kod pisany przez algorytmy: Błogosławieństwo czy klątwa dla maintainerów?
Bezprecedensowy skok liczby commitów obnaża nową rzeczywistość rozwoju jądra: lawinowy wzrost poprawek generowanych przez zaawansowane fuzzery (jak zasilany nowymi modelami uczenia maszynowego Syzkaller) oraz agentów AI analizujących kod statycznie.
Z technicznego punktu widzenia, modele językowe (ang. LLMs) świetnie radzą sobie z wyłapywaniem wycieków pamięci (ang. memory leaks), brakujących sprawdzeń wskaźników (ang. null-pointer dereference) czy błędów typu use-after-free w rzadko używanych sterownikach. Problem w tym, że masowe generowanie takich mikropoprawek drastycznie obniża stosunek sygnału do szumu (signal-to-noise ratio). Opiekunowie poszczególnych podsystemów są bombardowani trywialnymi łatkami, z których część „naprawia” kod w sposób mechaniczny, psując jednocześnie spójność logiczną lub wprowadzając subtelne regresje wydajnościowe (np. poprzez niewłaściwe umiejscowienie blokad spinlock). W korporacyjnym cyklu życia jądra, gdzie proces code review jest świętością, automatyzacja ofensywna po stronie AI stała się niespodziewanym wąskim gardłem dla ludzkich inżynierów.
Rewolucja w ext4: iomap zastępuje wysłużone buffer_head
Wśród blisko 20 tysięcy zmian, absolutnym hitem inżynieryjnym jest pakiet 31 patchy od Zhang Yi, wprowadzający nową, opcjonalną architekturę wejścia/wyjścia dla ext4. Zaimplementowano buforowaną ścieżkę opartą na infrastrukturze iomap dla zwykłych plików (aktywowaną opcją montowania buffered_iomap).
Aby zrozumieć wagę tej zmiany, trzeba zajrzeć pod maskę warstwy VFS (Virtual File System). Tradycyjnie ext4 opierał się na strukturach buffer_head, które mapują bloki dyskowe w stosunku 1:1 do stron pamięci (page cache). To rozwiązanie z lat 90., które przy dzisiejszych pojemnościach i prędkościach NVMe generuje potężny narzut na alokację pamięci, blokady i śledzenie stanu każdego pojedynczego bloku z osobna. iomap, rozwijane początkowo dla XFS, całkowicie omija ten problem, operując na większych, ciągłych zakresach danych (extentach) i natywnie integrując się z nowoczesnym mechanizmem folios (stron pamięci o zmiennym rozmiarze).
Pomiary wydajności nowej architektury tłumaczą, dlaczego gra jest warta świeczki:
- Zapis 1 MiB bez pamięci podręcznej (uncached): wzrost o 105% (z 1.404 do 2.883 MiB/s). To bezpośredni efekt wyeliminowania setek operacji alokacji
buffer_headprzy dużych, ciągłych transferach. iomap po prostu deleguje cały duży extent jednym ciągiem. - Zapis 64 KiB bez pamięci podręcznej: wzrost o 68% (z 415 do 698 MiB/s).
- Zapis 1 MiB z pamięcią podręczną stron (page cache): wzrost o 35% (z 4.295 do 5.780 MiB/s). Zmniejszona rywalizacja o blokady (lock contention) na strukturach pamięci.
- Zapis 1 KiB z fsync po każdym zapisie: spadek o 15% (z 0,71 do 0,60 MiB/s). Architektura iomap posiada nieco wyższy narzut inicjalizacyjny (setup overhead). Przy ekstremalnie małych transakcjach wymuszających natychmiastowy zrzut z dziennika (fsync), stara i mocno zoptymalizowana ścieżka
buffer_headwciąż radzi sobie minimalnie lepiej.
Haczyki, kompatybilność i data=journal
Ścieżka iomap w ext4 jest obecnie w fazie wczesnej adopcji i zachowuje się jak precyzyjny skalpel – wyłącza się automatycznie i robi fallback do starej trasy, gdy natrafi na zaawansowane funkcje systemu plików, dla których nie ma jeszcze napisanej logiki mapowania. Obejmuje to inody bez ekstentów (starsze systemy plików po konwersji z ext3), włączoną defragmentację online, atrybuty fs-verity (kryptograficzna weryfikacja plików), fscrypt oraz dane przechowywane bezpośrednio w inodzie (inline data).
Dla administratorów kluczowy będzie fakt, że nowa trasa drastycznie różni się w obsłudze spójności przy nagłych awariach (crash consistency). iomap omija całkowicie tryb data=order (gdzie dane są wymuszane na dysku przed zatwierdzeniem metadanych w dzienniku). Co więcej, z oczywistych względów wydajnościowych, nie współpracuje z trybem data=journal (gdzie wszystko, łącznie z danymi pliku, ląduje najpierw w jfs).
Wdrażanie Linuksa 7.4-rc1 w środowiskach, w których stabilność zasilania i integralność bazy danych mają absolutny priorytet, będzie wymagało rygorystycznych testów nowej opcji buffered_iomap. Jądro wkracza w fazę głębokiej modernizacji długu technologicznego, co w perspektywie długoterminowej zagwarantuje nam potężny wzrost IOPS, ale w krótkim czasie wymaga od nas trzymania ręki na pulsie w kwestiach flag montowania.
