A Huawei fejlesztője, Baokun Li egy nagyszabású, huszonöt javításból álló patchet terjesztett be a Linux kernelhez, amely lehetővé teszi az EXT4 fájlrendszer számára, hogy a lapméretnél nagyobb blokkmérettel működjön. A fejlesztés, amelyet a 6.18-rc2 kernelverzióra építettek, a fájlrendszer alapvető működését érinti, és egy új mérföldkő a nagy teljesítményű adattárolás felé. Mivel a Linux már támogatja a nagyobb, úgynevezett „large folio” lapokat a hagyományos fájlok esetében, a szükséges módosítások nem drasztikusak, de szétszórtan érintik az ext4 kódját. A fő változások a lehetséges osztási hibák és eltolási problémák kiküszöbölésére, valamint az egymást kizáró csatolási opciók kezelésére irányulnak.
Tartalomjegyzék
Technikai kihívások és megoldások
A fejlesztés egyik technikailag érzékeny pontja az volt, hogy amikor az ext4 és a naplózó alrendszer, a jbd2 nagyobb, mint order-1 oldalakat próbált lefoglalni az __alloc_pages_slowpath() függvényen keresztül az __GFP_NOFAIL flaggel, a rendszer váratlan figyelmeztetéseket generált. Az új patch-sorozat ezt úgy oldja meg, hogy a nagyobb lapok lefoglalásakor a kritikus flag nem kerül továbbításra, helyette a függvények belső újrapróbálkozási logikát használnak a stabil allokáció érdekében. A változtatások számos fájlban megjelennek, többek között az fs/ext4/ és az fs/jbd2/ könyvtárakban, és céljuk, hogy a fájlrendszer minden szinten képes legyen a nagy blokkméretek kezelésére, akár 64 kilobájtig.
A fejlesztés hatása az ext4 teljesítményére és a jövőbeli irány
A tesztelés során a módosított rendszerrel lefuttatott kvm-xfstests vizsgálatok semmilyen új hibát vagy kernelösszeomlást nem mutattak. A mérések alapján az ext4 írási teljesítménye a klasszikus 4 kilobájtos blokk esetén gyakorlatilag változatlan maradt, miközben a nagyobb blokkokat használó konfigurációk esetében a BIO-alapú írási teljesítmény átlagosan 50 százalékkal nőttek a korábbi bigalloc megoldáshoz képest. Ugyanakkor a DIO-műveletek esetében teljesítménycsökkenést tapasztaltak, amely a blokk méretének növekedésével és a tesztelésnél használt kisebb adatblokkokkal arányosan akár 30 százalékos is lehet. A regresszió oka az, hogy a blokkalapú ellenőrzőösszeg-számítások, különösen a crc32c_arch() rutin futásideje jelentősen megnőtt. A fejlesztő hangsúlyozta, hogy a nagyobb blokkméret nem minden munkaterhelés esetében előnyös, ezért a felhasználóknak az I/O-mintázatukhoz illő beállítást érdemes választaniuk.
A Baokun Li által vezetett fejlesztés az ext4 egyik legjelentősebb előrelépése az utóbbi években, amely a modern hardverekhez igazodó, rugalmasabb blokkméret-támogatást tesz lehetővé. A teljesítménytesztek ígéretes eredményeket mutatnak, és a jövőben további optimalizációkat terveznek a blokkelosztási algoritmusok terén, hogy az ext4 még hatékonyabban kezelje a nagy adatmennyiségeket. A fejlesztés stabilitása és kompatibilitása már most bizonyított, így a funkció várhatóan hamarosan beolvad a fővonalas kernelbe.
