Thorsten Leemhuis nyílt levele az Oracle-nek és a SUSE-nak.

Az Oracle és a SUSE annak ellenére támogatja a btrfs-t, hogy nem bizonyított még éles környezetben és hivatalosan még mindig kísérleti állapotban van. Továbbá eme két disztribútor azelőtt adta ki a fájlrendszer ellenőrző és javító btrfsck-t, hogy azt a Linux közösség tesztelte volna.

Kedves fejlesztők és döntéshozók az Oracle-nél és a SUSE-nél!

Csodálom a bátorságotokat, hogy hivatalos támogatást nyújtotok a még kísérleti stádiumban lévő btrfs fájlrendszerhez a legutóbbi Oracle Linux és SUSE Linux Enterprise frissítésben. A széleskörűbb használattal javulni fog a „következő generációsnak” kikiáltott Linux fájlrendszer stabilitása.

Ennek ellenére én a helyetekben nem aludnék jól az elkövetkező hetekben.

Biztos vagyok benne, hogy alaposan átgondoltátok. Azt is tudom, hogy az alkalmazottaitok hozzájárulnak a btrfs-hez és széleskörűen tesztelik őket. Még a btrfs atyja és fő fejlesztője, Chris Mason is az Oracle-től kapja a fizetését. Ennek ellenére jól tudjátok, hogy mindegy, mennyire van egy program tesztelve, bizonyos esetek még a legalaposabb tesztekben sem jönnek elő. Ezeket jól szimbolizálják a lezuhanó műholdak vagy a felrobbanó rakéták.

Hogy a fizető ügyfeleket a lehető legtöbb hibától megkíméljék, a SUSE-nél a – Red Hat-féle Fedora mintájára – elindították az openSUSE projektet. Ezek bárki számára szabadon elérhető terjesztések. Az üzemeltetési sajátosságok, valamint az elérhető hardverek és szoftverek sokfélesége olyan hibákat okozhat, melyeket egy tesztlabor értelmes időben képtelen produkálni. Ezeket a hibákat a felhasználók jelentik. Közelebbről megtekintve az eddigieket, az egyik kifejezetten meglepett, ugyanis igen komolynak tűnik, és még mindig ott leselkedik a szoftverben. Egy olyan szoftverben, melyet általánosan kiforrottnak és stabilnak nyilvánítottak.

Minden hasonló probléma javításával a kiadás egy kicsit jobb lesz. A Red Hat Enterprise Linux (RHEL) és a SUSE Linux Enterprise (SLE), melyek a Fedorán és openSUSE-n alapszanak, kifejezetten sokat hasznosítanak ezekből a javításokból. Támogatási szerződések keretében cégek fizetnek a RHEL vagy SLE használatáért vagy épp az Oracle Linux-ért, ami RHEL alapú.

De úgy tűnik, hogy ti, az Oracle-nél és a SUSE-nél annyira várjátok a btrfs-t, hogy azt a közösségi disztribúciók tesztelése nélkül adjátok ki.

Persze, egy ideje már elérhető a btrfs mind az openSUSE-ban, mind a Fedorában. Azonban a Fedorában többszöri próbálkozás után sem lett alapértelmezett fájlrendszer, ahogy sem Ubuntuban, sem pedig más, nagyobb disztribúcióban nem bátorkodtak ezt meglépni. Ebből következik, hogy a btrfs-t legjobb esetben is csak azok a felhasználók tesztelték, akik átgondolták, hogy számukra melyik fájlrendszer lenne ideális és nem ijedtek meg a „kísérleti” jelzéstől, melyet még a Linux kernel jelenlegi, 3.3-as verziójában lévő btrfs is tartalmaz. Ez pedig a felhasználók egy igen is százaléka lehetett. Akik pedig használják, még mindig jelentik a hibákat, melyek megnézhetőek a levelező listán, ahol a btrfs fejlesztők egymással beszélgetnek. Például tavaly év végén a fejlesztők olyan hibát javítottak, ami fájlrendszer hibát okozhat összeomlás vagy áramszünet esetén Linux 3.2-ben.

Apropó sérült fájlrendszerek: a btrfs legalább itt-ott tesztelve van, de még ennyi sem mondható el az ellenőrző és javító eszközéről, ami már hónapok óta készül. A „fejlesztett” btrfsck, amit szállítotok önmagában még nem elérhető. Úgy tűnik, a kódotok a „btrfs tools” git ágából származik, mely a sokat sejtető „dangerdonteveruse” (veszélyes, soha ne használd) néven érhető el.

Ha csak az egyszerű, asztali alkalmazásról beszélnénk, akkor talán még együtt tudnék élni az elégtelen teszteléssel. De a fájlrendszer, amire rábízom az értékes adataimat, még megfelelő mentési rendszerrel együtt is igen kényes kérdés. Főleg úgy, hogy Kernel Log kutatásaim közben rendszeresen találok az új kernel kiadásokban olyan, régóta stabilnak mondott fájlrendszerekhez is javításokat mint az ext3 és az ext4. Minden szoftver tartalmaz hibákat, amiket meg kell találni és javítani kell. Ez pedig különösen igaz az új, még nem bizonyított kódra.

Ez még nem minden, mivel a btrfs még nincs kész. A fejlesztők még mindig dolgoznak a RAID-5 támogatáson, a hatékonyabb tömörítési algoritmusokon és további fejlesztéseken. Bár néhány képesség a későbbiekben is hozzáadható, jó ötlet dolgozni még néhány további optimalizáción. Például köztudott, hogy a btrfs nem igazán ideális virtuális gépek lemezképeinek tárolására. Több esetben is rosszabb a hatékonysága mint az ext4-nek vagy az xfs-nek, ha adatbázist tárolunk rajta. Ez a Copy-on-Write (CoW) mechanizmus miatt van. Elsődlegesen ebből származik a btrfs legtöbb előnye. Ugyanakkor van néhány hátránya is, melyek kiküszöbölésén vagy hatásainak minimalizálásán még dolgoznak a fejlesztők – nyilvánvalóan meg kellene várni, míg elkészülnek.

Igazán kíváncsi vagyok, hogy a frissítésekkel és kiegészítésekkel ellátott vállalati disztribúcióitokban hogyan fog éles körülmények között teljesíteni a btrfs. Nem lennék meglepve, ha a „következő generációs” Linux fájlrendszer hírneve komoly csorbát szenvedne, ha egy komolyabb hiba bukkan fel. Mert jó pár hibának lennie kell. A fájlrendszernek be kell lépnie egy következő fejlesztési ciklusba, mielőtt „btrfs2” néven meghódítja a Linux világát.

Thorsten Leemhuis

Ez a cikk egy fordítás. Az eredetit elolvashatod itt: http://www.h-online.com/open/features/Kernel-Comment-Btrfs-too-fast-1473...