Teodoro Ts’o (Theodore Ts’o), az Ext4 fájlrendszer alkotója gondolatainak fordítása az ext4 fejlesztéséről, a BcacheFS fájlrendszerről, a Linux kernéről, ZFS-ről, a viselkedési kódexről és a fájlrendszerekről általában:
Az ext4 fejlesztéséről.
Az ext4 kernel kiadásokba több mint egy tucat ember járul hozzá. Jelenleg a legtöbb időmet a kód ellenőrzésére, tesztelésre és a tesztelési alkalmazás javítására fordítom {kvm,gce,qemu,android}-xfstests. Nagyon támaszkodom 2-3 másik fejlesztőre, akik a SUSE és az IBM-nél dolgoznak, és akik segítenek nekem a kód ellenőrzésében.
A BcacheFS-ről
Őszintén szólva, a bcachefs nem egy teljesen egyedülálló projekt — például Kent a 6.11 és 6.12 kernel kiadások között a patch-ek 72%-át írta, míg az ext4-re vonatkozó 103 patch közül 0%-ot én. Ennek az az oka, hogy határozottan hiszek abban, hogy a programozás csapatmunka, és technikai vezetőként az a feladatom, hogy lehetőséget biztosítsak az ext4 résztvevőinek arra, hogy mindent megtegyenek a fájlrendszer javítása érdekében. Hetente konferenciákat tartunk, és Derrick Wong, az XFS vezető fejlesztője és a korábbi XFS karbantartó részt vesz ezeken a konferenciákon — és tudvalevő, hogy segítettem neki az XFS tesztelési kérdésekben, míg Derrick segített nekem a különböző ext4 tesztelési kérdésekben, és még néhány ext4 patch-t is megvizsgált. Együttműködünk egymással, és ez jó.
Hagyom másoknak eldönteni, akarnak-e bízni valakiben, aki egyedülálló, tehetséges programozó lehet, de adok egy tippot — „csalni” is lehet, ha csapatot vonunk be a probléma megoldásába. Nem szükséges egyedül csinálni. Persze ehhez tudni kell, hogyan lehet a legjobbat kihozni másokból, és együtt kell dolgozni. A mások iránti udvarias viselkedés a levelezőlistákon sem árt.
A kernelt, CoC-t, a lehetőségeket és az ext4 jövőjét illetően
Az Ext4 valóban új funkciókat kap, de ezek olyanok, amelyeket a cégek hajlandók finanszírozni, mivel a funkciók kifejlesztésének megtérülése költség és előny szempontjából értelmes. Például a fscrypt és a kisbetű-érzéketlen könyvtárak olyan funkciók voltak, amelyek hasznosak voltak az Android és a Chrome OS számára, és ezeket legalább részben ezek a fejlesztőcsoportok finanszírozták (a Steam is aggódott a kisbetűérzékenység miatt, és támogatta az egyik mérnököt). Szeretnénk hozzáadni a törés nélküli (untorn) írás támogatását, mert ez javítja az adatbázisok teljesítményét a felhőben emulált blokkeszközökön, ahol garantálni lehet a 16k atomikus írásokat, ez lehetővé teszi a dupla pufferezés megszüntetését a MySQL és PostgreSQL esetében.
(Valójában az Amazon és a Google megteheti ezt saját DB termékeikben, feltételezve, hogyan működik az Amazon EBS és a Google Persistent Disk, de mi szeretnénk ezt általánosabb módon megvalósítani, amely hosszú távon fenntarthatóbb lesz). Ez kevésbé vonzó, mint az olyan dolgok, mint a reflinks, de a megtérülés sokkal könnyebben indokolható, mivel a költségek alacsonyabbak (kevesebb munka a fejlesztésnél, tesztelésnél és az üzleti telepítések minősítésénél), és az előnyök mennyiségi értékelése is sokkal könnyebb. Olyan dolgok, mint a „megtakaríthatom XX teljes munkaidős programozó bérét öt év alatt” sokkal könnyebben megvalósíthatók az ilyen jellegű teljesítményjavító funkciók esetében.
Ezzel szemben a reflinks szórakoztató, de nem találtam olyan ügyfelet, aki hajlandó lenne finanszírozni a fejlesztési költségeket, vagy olyan céget, amely úgy véli, hogy az ügyfelei többet vásárolnának a termékükből, ha reflinks funkciót adnak az ext4-hez. Ez borzalmasan vállalatiasnak tűnhet, de van egy történet arról, hogyan indították a ZFS mérnökei a projektet a nulláról, anélkül, hogy engedélyt kértek volna a vezetőségtől, és nem kaptak visszajelzést az értékesítési osztálytól, és bemutatták a Sunt, ami gyakorlatilag kész tény volt.
Jól hangzik, de ha eszünkbe jut, hogy a Sun végül pénzt kezdett veszíteni, míg kénytelen volt magát eladni egy másik cégnek, és gyakorlatilag a ZFS-t támogató mérnöki szervezet már nem létezik. Körülbelül abban az időben, amikor a ZFS-t bejelentették, részt vettem a cég egészének kutatásában, hogy van-e értelme beruházni fájlrendszer funkciókba az AIX és a Linux számára — és arra a következtetésre jutottunk, hogy nem, a megtérülés kicsi, és az új fájlrendszer funkciók nem fognak több ügyfelet vonzani, akik a berendezést, szoftvert vagy IBM rendszereket vásárolnak. Talán nehéz idők jöttek az IBM-re, de még mindig létezik, míg a Sun — nem.
Körülbelül ebben az időben több Linux-cég képviselői összeültek, hogy kitalálják, hogyan versenyezzen a Linux a ZFS-sel. Ezen a találkozón merült fel az ötlet, hogy a btrfs hosszú távú válasz lesz, míg az ext4 rövid távú megoldást jelent, amely támogatni fogja az olyan dolgokat, mint a valós idejű méretezés, a 64 bites blokkazonosítók és más dolgok, amelyek a hagyományos Legacy Unix OS-ekben voltak, de az ext3-ban nem.
Ezen a találkozón megkértek, hogy határozzam meg, mire lesz szükség egy teljesen új fájlrendszer létrehozásához. Kutatást végeztem, megnéztem, mennyi erőfeszítés kellett olyan fájlrendszerek létrehozásához, mint az IBM GPFS és JFS, a Digital advfs, értékeltem, mennyibe került a Sun-nak a ZFS létrehozása és a fájlrendszer ipari használatra való előkészítése. Az eredmény, amit kaptam, körülbelül 100 emberévet jelentett, alacsony becsléssel 50 emberévre és magas becsléssel 200 emberévre (de ez a GPFS-re vonatkozott, amely klaszter fájlrendszer volt, így sokkal bonyolultabb).
Erről beszámoltam a megbeszélésen, és egy Intel egyik vezető mérnöke azt mondta: „Ne mondja el ezt a vezetőknek, mert sosem fogják jóváhagyni a projektet! Mondja nekik, hogy a btrfs 18 hónap múlva kész lesz.” Hagyom, hogy az emberek maguk döntsenek arról, hogy mikor éri el a btrfs a „vállalati használatra kész” státuszt, különösen azok számára az új, vonzó, kiterjesztett funkciók esetében, amelyek a ZFS-zel versenyeztek, de nem hiszem, hogy meg kellene vitatni, hogy ez nem 18 hónapon belül történt.
Sőt, még mielőtt a Sun feloszlott volna, sok vállalat, amelyik képviselőit a találkozóra küldte, visszalépett attól, hogy mérnökeik részt vegyenek a btrfs fejlesztésében, ami természetesen nem segített. Valószínűleg ennek az az oka, hogy a vállalatok racionális szervezetek, amelyek saját befektetési megtérülési döntéseket hoznak, és az új fájlrendszer finanszírozása nem tűnt olyan értelmesnek, mint az, hogy azt mondják az embereknek, hogy a Linuxnak van válasza a ZFS-re.
Visszapillantva elmondható, hogy bár a ZFS valóban rendelkezett néhány nagyszerű funkcióval, ezek nem voltak elegendőek ahhoz, hogy a legtöbb felhasználót arra ösztönözzék, hogy a Solaris-t válassza a sokkal olcsóbb x86 platformok vásárlása helyett és Linux telepítése mellett. Mire a Sun próbálta az OpenSolaris és az x86 Solaris stratégiát, már túl késő volt. A hálózati hatások óriásiak voltak, és az x86 stratégia nem adta meg a választ arra a kérdésre, hogy egyetlen cég, a Sun, hogyan tudott fizetni a Solaris fejlesztésén dolgozó hihetetlenül tehetséges mérnököknek. Egy 5000 dolláros x86 szerver vásárlása nem nyújt nagy értékesítési megtérülést a szerverrel 100000 dolláros SunFire E10k Sparc-hoz képest, amelyet a Sun a "dot Com" "pontjának" nevezett.
A lényeg az, hogy a való világban végzett mérnöki munka mindig kompromisszumokat jelent, és az üzleti realitások részei ennek a kompromisszumnak. Nem szégyellem, hogy inkább ételt eszem, és hogy szeretnék elegendő pénzt keresni ahhoz, hogy egy nap nyugdíjba vonulhassak. Ennek következményeként jól kell értenem, hogyan hozok hasznot a munkáltatómnak, legalább tízszeresen meghaladva a fizetésemet. Ha ezt el tudom érni, miközben nyílt forráskódú projektekben dolgozom és segítek más cégeknek pénzt keresni, hogy készségesebben hozzájáruljanak az ext4-hez, ez része a kihívásnak, és azért szeretek nyílt forráskódú fejlesztésekkel foglalkozni.
A visszatérve a magatartási kódexhez, elmondhatom, hogy a legtöbb fájlrendszer karbantartója nem valamilyen lanyha liberális megfontolás miatt támogatta a kódexet. Arra van szükségünk, hogy minden mérnök, aki készen áll arra, hogy hozzájáruljon a projektünkhöz, vele legyen, és a legtöbben láttuk már olyan embereket, akik elhagyták a Linuxot, és más operációs rendszerekre váltottak (ismerek egy embert, aki Windowsra váltott, és értékes Linux kernel fejlesztő volt az IBM Linux Technology Centerben), vagy belső projekteken dolgoztak, de nem ezen az LKML-t igénylő területen, a levlistán néhány ember mérgező légköre miatt.
Bizonyos esetekben az aggodalmak indokolatlanok voltak; például Linus üvöltött egy tapasztalt fejlesztővel, akinek tényleg tudnia kellett volna jobban, és akivel Linus a legtöbb esetben személyesen találkozott, és már kialakult kapcsolatuk volt. A probléma az, hogy az újoncok nem tudták ezt, és megijedtek – "Mi van, ha Linus nyilvánosan megaláz engem, ahogy Steve-vel tette?" nem értve, hogy a gyakorlatban ez nem fog megtörténni. Ezért van a CoC; nem nekünk, idősebb mérnököknek, hanem a fiatalabb mérnökök támogatására a csapatainkban, akiket szeretnénk képezni, hogy egy időpontban helyettesíthessenek minket, amikor elérkezik az idő a nyugdíjhoz, vagy elüt minket egy busz, vagy más módon távozunk ebből a múlandó világból.
Ne feledjétek, hogy 50-100 emberévet dolgoztunk egy vállalati környezetben használható fájlrendszer létrehozásáért. Minden mérnökre szükségünk van, akit csak meg tudunk nyerni, és sokan közülünk szabadidőnkben plusz munkát végeznek, mert nem mindegy nekünk. Egy magas színvonalú fájlrendszer létrehozása csapatmunka, és minden tehetséges mérnökre szükségünk van, akit csak meg tudunk szerezni. Még ha egy mérnök szuper 10x-es programozó is, ha végül elriaszt egy rakás más mérnököt, akik részt vehetnek a tesztelésben, teljesítményoptimalizálásban stb., az nem éri meg, hogy valaki gazember legyen.
Forrás: opennet.ru
