Překlad úvah Teodora Ts’o (Theodore Ts’o), tvůrce souborového systému Ext4, o vývoji ext4, souborovém systému BcacheFS, jádru Linux, ZFS, kodexu chování a souborových systémech obecně:
O vývoji ext4.
Do každého vydání jádra ext4 přispívá více než půl tuctu lidí. V současné době trávím většinu svého času revizí kódu, prováděním testů a zlepšováním testovací aplikace {kvm,gce,qemu,android}-xfstests. A velmi se spoléhám na 2-3 další vývojáře pracující v SUSE a IBM, kteří mi pomáhají s revizí kódu.
O BcacheFS
Pokud mám být upřímný, bcachefs není zcela samostatný projekt – například Kent byl autorem 72% patchů mezi vydáními jádra 6.11 a 6.12, zatímco z 103 patchů k ext4 za stejné období jsem byl autorem přesně 0%. To proto, že pevně věřím, že programování je týmový sport, a moje úloha jako technického vedoucího spočívá v tom, abych umožnil účastníkům ext4 udělat vše pro zlepšení souborového systému. Pořádáme týdenní konference, a Derrick Wong, senior vývojář XFS a bývalý správce XFS, se těchto konferencí účastní – a jako je známo, pomáhal jsem mu s testováním XFS, a Derrick mi pomáhal s různými otázkami testování ext4 a dokonce zvažoval několik patchů ext4. Spolupracujeme spolu a to je dobré.
Dávám ostatním lidem na rozhodnutí, zda chtějí svěřit svá data někomu, kdo je osamělým nadaným programátorem, který může být mnohem talentovanější než já, ale dám vám tip - můžete "podvádět" tím, že přivedete tým k řešení problému. Není nutné to dělat osamotě. Samozřejmě, že k tomu musíte vědět, jak probudit to nejlepší v ostatních a musíte spolupracovat. A zdvořilé chování v mailing listech neškodí.
O jádře, CoC, možnostech a budoucnosti ext4
Ext4 skutečně dostává některé nové funkce, ale jsou to ty, které firmy jsou ochotny financovat, protože návratnost investic do vývoje funkce dává smysl z hlediska nákladů a přínosů. Například fscrypt a adresáře bez ohledu na velká a malá písmena byly funkce, které byly užitečné pro Android a Chrome OS, a byly financovány, alespoň částečně, těmito vývojářskými skupinami (Steam se také obával o ohýbání velkých písmen a podpořil jednoho z inženýrů). Chceme přidat podporu pro zápis bez přerušení (untorn), protože to zlepší výkon databází na cloudových emulovaných blokových zařízeních, kde lze zaručit 16k atomárních zápisů, což umožní zbavit se dvojího bufferingu v MySQL a PostgreSQL.
(Ve skutečnosti to může udělat Amazon a Google ve svých vlastních produktech DB tím, že učiní předpoklady o tom, jak fungují Amazon EBS a Google Persistent Disk, ale chceme to udělat obecnějším způsobem, který bude dlouhodobě udržitelnější). Není to tak atraktivní jako například reflinks, ale návratnost investic je mnohem snazší obhájit, jak proto, že náklady jsou nižší (méně práce na vývoji, testování a kvalifikaci pro firemní nasazení), tak proto, že přínosy jsou mnohem snazší kvantitativně vyhodnotit. Takové věci jako „mohu ušetřit náklady na mzdy XX zaměstnanců programátorů po dobu pěti let“ jsou mnohem snazší provést pro takovéto typy funkcí zvyšující výkon.
Na rozdíl od toho, reflinks jsou zábavné, ale nenašel jsem klienta, který by byl ochoten zaplatit náklady na vývoj, nebo firmu, která by věřila, že jejich zákazníci budou kupovat více jejich produktu, pokud přidají reflinks do ext4. Může to znít hrozně korporátně, ale existuje příběh o tom, jak inženýři ZFS začali projekt od nuly, aniž by požádali vedení o povolení nebo obdrželi podněty od obchodního oddělení, a představili Sun, co bylo ve skutečnosti hotovou věcí.
Zní to skvěle, ale když si vzpomeneme, že Sun nakonec začala prodělávat, až byla nucena se prodat jiné společnosti, a že inženýrská organizace podporující ZFS již neexistuje. Přibližně v době, kdy byl ZFS oznámen, jsem se účastnil firemního výzkumu, abych zjistil, zda má smysl investovat do funkcí souborového systému pro AIX a Linux — a dospěli jsme k závěru, že ne, návratnost investic je malá a nové funkce souborového systému nepovedou k nárůstu zákazníků kupujících hardware, software nebo systémy IBM. Možná pro IBM nastaly těžké časy, ale stále existuje, zatímco Sun ne.
Přibližně ve stejnou dobu se sešli zástupci několika linuxových společností, aby vymysleli, jak bude Linux konkurovat ZFS. Na tomto setkání byla navržena myšlenka, že btrfs bude dlouhodobou odpovědí, zatímco ext4 bude krátkodobým řešením, které zajistí podporu takových věcí, jako je změna velikosti za běhu, 64bitová čísla bloků a další funkce, které byly v tradičních legacy Unix OS a které chyběly v ext3.
Na této schůzce jsem byl požádán, abych určil, co bude potřeba k vytvoření zcela nového souborového systému. Prozkoumal jsem, kolik úsilí bylo potřeba pro vytvoření souborových systémů jako GPFS a JFS od IBM, advfs od Digital, posoudil jsem, kolik času Sun potřeboval na vytvoření ZFS a přivedení tohoto souborového systému do stavu plně připraveného na výrobu. Odpověď, kterou jsem dostal, byla přibližně 100 osoboklet, s nízkým odhadem 50 osoboklet a vysokým odhadem 200 osoboklet (ale to bylo pro GPFS, který byl clusterovým souborovým systémem, a proto mnohem složitější).
Oznámil jsem to na schůzce a jistý starší inženýr z Intelu řekl: „Ne, o tom neříkejte vedení, protože nikdy neschválí projekt! Řekněte jim, že btrfs bude připraven za 18 měsíců.“ Nechávám na lidech, aby rozhodli, kdy btrfs dosáhne stavu „připravenosti pro komerční použití“, zejména pro ty nové atraktivní rozšířené funkce, které měly konkurovat ZFS, ale nemyslím si, že je k diskusi to, že se to nestalo za 18 měsíců.
A dokonce již před tím, než se Sun rozpadla, mnoho společností, které poslaly své zástupce na schůzku, odmítlo, aby inženýři pracovali na btrfs, a to samozřejmě nepomohlo. Pravděpodobně to bylo způsobeno tím, že společnosti — racionální organizace, které se rozhodují na základě návratnosti investic, a financování nového souborového systému nemělo stejný smysl, jako vyprávět lidem, že Linux bude mít odpověď na ZFS.
Když se ohlédneme zpět, můžeme říci, že i když ZFS mělo ty opravdu skvělé funkce, nebylo jich dost na to, aby většinu uživatelů přiměly vybrat si Solaris místo toho, aby si pořídili mnohem levnější platformy x86 a nainstalovali Linux. A když se Sun rozhodla vyzkoušet strategii OpenSolaris a Solaris x86, bylo už příliš pozdě. Síťové efekty byly obrovské, a strategie x86 nedokázala odpovědět na otázku, jak jedna společnost, Sun, mohla platit mzdy všem super talentovaným inženýrům, kteří pracovali na Solaris. Nákup x86-serveru za 5000 dolarů nenabízí velkou návratnost investic ve srovnání s serverem SunFire E10k Sparc za 100000 dolarů, který Sun nazývala "point" v "dot Com."
Podstatou je, že inženýrská činnost ve skutečném světě je kompromis a obchodní realita je součástí tohoto kompromisu. Neomlouvám se za to, že dávám přednost jídlu a že chci vydělávat dostatek peněz, abych se jednou mohl důchodově usadit. A to zase znamená, že musím dobře rozumět tomu, jak přináším zaměstnavateli hodnotu, která alespoň desetkrát převyšuje můj plat. Pokud to budu moci udělat, přičemž budu i nadále pracovat s otevřeným zdrojovým kódem a pomáhat jiným společnostem vydělávat peníze, aby byly ochotny přispět do ext4, nu, to je součást výzvy a důvod, proč miluji práci s otevřeným zdrojovým kódem.
A pokud se vrátím k Etickému kodexu, řeknu, že téměř všichni udržovatelé hlavních souborových systémů podporovali Kodex nikoli kvůli nějakým vlažným liberálním úvahám. Protože potřebujeme každého inženýra, který je ochoten přispět do našeho projektu, a většina z nás viděla lidi, kteří odmítali pracovat v Linuxu a přešli k jiným operačním systémům (znám jednoho člověka, který přešel na Windows a byl cenným vývojářem jádra Linuxu v IBM Linux Technology Center) nebo pracovali na interních projektech, ale ne na těch, které vyžadovaly interakci s LKML, kvůli toxickému prostředí několika lidí na mailing listu.
V některých případech byly obavy neopodstatněné; například Linus křičel na staršího vývojáře, který měl skutečně vědět lépe a se kterým se Linus v drtivé většině případů osobně setkal, takže mezi nimi už existovaly určité vztahy. Problém je v tom, že nováčci toto nevěděli a báli se — „a co když mě Linus veřejně poníží stejně jako Stevea“, aniž by chápali, že se to v praxi nestane. Proto máme CoC; není to pro nás, starší inženýry, ale pro podporu mladších inženýrů v našich týmech, které chceme vycvičit, aby nás v určitém okamžiku nahradili, až přijde čas na odchod na důchod, nebo nás srazí autobus, nebo jinak opustíme tento pomíjivý svět.
Nezapomínejte na 50-100 pracovníků let věnovaných vytváření souborového systému připraveného pro použití v podnikových prostředích. Potřebujeme všechny inženýry, které můžeme získat, a mnoho z nás vykonává dodatečnou práci ve svém volném čase, protože nám není jedno. Vytváření vysoce kvalitního souborového systému je týmová práce a potřebujeme každého talentovaného inženýra, kterého můžeme získat. I když je jeden inženýr super 10x programátor, pokud nakonec odradí spoustu dalších inženýrů, kteří mohou pracovat na testování, optimalizaci výkonu atd., prostě to nestojí za to, aby někdo byl zlý.
Zdroj: opennet.ru
