Превод на размислите на Теодор Ц’о (Theodore Ts’o), създателя на файловата система Ext4, относно разработката на ext4, файловата система BcacheFS, ядрото на Linux, ZFS, кодекса на поведение и файловите системи като цяло:
За разработката на ext4.
В всяко издание на ядрото ext4 участват повече от дузина хора. В момента голяма част от времето ми е отделено за преглед на кода, провеждане на тестове и подобряване на тестовото приложение {kvm,gce,qemu,android}-xfstests. И много разчитам на 2-3 разработчици от SUSE и IBM, които ми помагат с прегледа на кода.
За BcacheFS
Ако бъда честен, bcachefs не е напълно самостоен проект — например, Кент е автор на 72% от патчовете между версиите на ядрото 6.11 и 6.12, докато от 103 патча за ext4 през същия период, аз съм автор точно на 0%. Това е, защото твърдо вярвам, че програмирането е отборен спорт и моята работа като технически ръководител е да дам възможност на участниците в ext4 да направят всичко възможно, за да подобрят файловата система. Провеждаме седмични конференции, а Дерик Уонг, старши разработчик на XFS и бивш поддръжник на XFS, участва в тези конференции — и аз, както е известно, му помагах по въпросите на тестването на XFS, а Дерик ми помагаше по различни въпроси на тестването на ext4 и дори разгледа няколко патча на ext4. Ние си сътрудничим и това е хубаво.
Аз давам на другите хора да решат дали искат да се доверят на някого, който е единствено талантлив програмист, който може да е по-талантлив от мен, но ще ви дам подказка — можете да 'измамите', привличайки екип за решаване на проблема. Не е нужно да го правите сами. Разбира се, за това трябва да знаете как да събудите най-доброто в другите и да работите заедно. И учтивото отношение един към друг в пощенските списъци няма да навреди.
За ядрото, CoC, възможностите и бъдещето на ext4
Ext4 наистина получава нови функции, но това са онези, които компаниите са готови да финансират, тъй като рентабилността на разработването на функцията има смисъл от гледна точка на разходите и ползите. Например, fscrypt и директории без разлика в регистъра бяха функции, полезни за Android и Chrome OS, и бяха финансирани, поне частично, от тези групи разработчици (Steam също се притесняваше за разликата в регистъра и подкрепи един от инженерите). Искаме да добавим поддръжка за непрекъснато записване (untorn), тъй като това ще подобри производителността на базите данни на облачни емулирани блочни устройства, където може да се гарантира 16k атомарни записи, което ще ни позволи да се отървем от двойното буфериране в MySQL и PostgreSQL.
(Всъщност Amazon и Google могат да направят това в собствените си СУБД-продукти, правейки предположения за начина, по който работят Amazon EBS и Google Persistent Disk, но ние искаме да го направим по-общо, което да е по-поддържано в дългосрочен план). Това е по-малко привлекателно от неща като reflinks, но възвръщаемостта на инвестициите е много по-лесна за обосноваване, както поради факта, че разходите са по-ниски (по-малко работа по разработката, тестването и квалификацията за корпоративно внедряване), така и защото ползите са много по-лесни за количествено оценяване. Неща като 'мога да спестя разходите на заплатата на XX инженери-програмисти в продължение на пет години', много по-лесно е да се направят за такива функции за повишаване на производителността.
В противовес этому, reflinks е весело, но не успях да намеря клиент, готов да плати разходите за разработка, или компания, която смята, че клиентите им ще купят повече от техния продукт, ако добавят reflinks в ext4. Това може да звучи ужасно корпоративно, но има история за това как инженери от ZFS започнали проект от нулата, без да питат разрешение от ръководството и без предложения от отдела за продажби, и представили на Sun нещо, което фактически било свършено.
Звучи страхотно, но ако си припомним, че в крайна сметка Sun започна да губи пари, докато не бе принудена да се продаде на друга компания, и фактически инжeнерната организация, която поддържаше ZFS, вече не съществува. Около времето, когато ZFS бе анонсиран, участвах в проучване на цялата компания относно това, дали има смисъл да инвестираме в функции на файловата система за AIX и Linux - и стигнахме до заключението, че не, възвращаемостта на инвестицията е малка, а новите функции на файловата система няма да доведат до увеличение на клиентите, купуващи оборудване, софтуер или системи IBM. Може би времето беше тежко за IBM, но тя все още съществува, а Sun - не.
Около същото време представители на няколко Linux компании се събраха, за да измислят как Linux ще конкурира с ZFS. Именно на тази среща бе изказана идеята, че btrfs ще бъде дългосрочен отговор, а ext4 - краткосрочно решение, което ще осигури поддръжка на неща като преместване в реално време, 64-битни блокови номера и други неща, които присъстваха в традиционните Legacy Unix OS и не бяха в ext3.
На тази среща ме помолиха да определя какво е необходимо за създаването на съвсем нова файловата система. Проведох проучване, поглеждайки колко усилия бяха вложени в създаването на файлови системи като GPFS и JFS от IBM, advfs от Digital, оценявайки колко време отне на Sun да създаде ZFS и да доведе тази файловата система до напълно готово за производството състояние. Отговорът, който получих, беше около 100 човекогодини, като една ниска оценка беше 50 човекогодини и висока оценка — 200 човекогодини (но това беше за GPFS, която беше кластерна файловата система и затова много по-сложна).
Обадих се на това на срещата, и един старши инженер от Intel каза: "Не, не им казвайте на ръководителите, защото те никога няма да одобрят проекта! Кажете им, че btrfs ще бъде готов за 18 месеца". Аз оставям на хората сами да решат кога btrfs ще достигне статуса "готов за корпоративна употреба", особено за новите привлекателни разширени функции, които трябваше да конкурират с ZFS, но не мисля, че е подлежащо на обсъждане, че това не се случи след 18 месеца.
И дори преди да се разпадне Sun, много компании, които изпратиха свои представители на срещата, се отказаха от участието на инженерите в работата по btrfs, и това, разбира се, не помогна. Но вероятно е свързано с факта, че компаниите са рационални организации, които вземат собствените си решения относно възвращаемостта на инвестициите, а финансирането на нова файлова система не имаше същия смисъл, както да се разказва на хората, че Linux ще има отговор на ZFS.
Оглеждайки се назад, можем да кажем, че, макар ZFS да имаше наистина страхотни функции, те не бяха достатъчни, за да накарат повечето потребители да изберат Solaris вместо да закупят много по-евтини x86 платформи и да инсталират Linux. И до момента, в който Sun реши да опита стратегията OpenSolaris и Solaris x86, вече беше твърде късно. Мрежовите ефекти бяха огромни, а стратегията x86 не даваше отговор на въпроса как една компания, Sun, можеше да плаща заплатите на всички суперталантливи инженери, работили по Solaris. Закупуването на x86 сървър за 5000 долара не предоставя добра възвръщаемост на продажбите в сравнение с сървър SunFire E10k Sparc за 100000 долара, който Sun наричаше "точката" в "dot Com".
Същността е, че инженерната дейност в реалния свят е компромис, а бизнес реалностите са част от този компромис. Не се извинявам, че предпочитам да ям храна и че искам да изкарвам достатъчно пари, за да мога един ден да се пенсионирам. А това, от своя страна, означава, че трябва да разбирам добре как нося полза на работодателя, поне 10 пъти над заплатата си. Ако мога да направя това, продължавайки да работя с отворен код и помагайки на другите компании да печелят пари, за да са готови да внесат своя принос в ext4, е, това е част от предизвикателството и причината, поради която обичам да работя с отворен код.
И, връщайки се към Кодекса на поведението, ще кажа, че почти всички поддържащи основните файлови системи одобриха Кодекса не поради някакви безсилни либерални съображения. Причината е, че се нуждаем от всеки инженер, готов да допринесе за нашия проект, и повечето от нас са виждали хора, които отказват да работят с Linux и се прехвърлят на други операционни системи (знам за един човек, който премина на Windows и бе ценен разработчик на ядрото на Linux в IBM Linux Technology Center) или работят по вътрешни проекти, но не и по такива, които изискват взаимодействие с LKML, заради токсичната среда на няколко души в имейл списъка.
В някои случаи опасенията бяха неоснователни; например, Линус викаше на старши разработчик, който наистина трябваше да знае по-добре и с когото Линус се срещаше лично в повечето случаи и те вече имаха установени отношения. Проблемът е, че новаците не знаеха това и се плашеха — "а ако Линус ме унижи публично, както е направил със Стив", не осъзнавайки, че на практика това няма да се случи. Ето защо имаме CoC; това не е за нас, старши инженери, а за поддържане на по-младите инженери в нашите екипи, които искаме да обучим, за да ни заменят, когато дойде времето за пенсия, или когато ни блъсне автобус, или по друг начин напуснем този бренен свят.
Не забравяйте за 50-100 човекогодини работа по създаването на файлова система, готова за корпоративна среда. Нуждаем се от всички инженери, които можем да привлечем, и много от нас извършват допълнителна работа в свободното си време, защото ни е грижа. Създаването на висококачествена файлова система е работа в екип и ни трябва всеки талантлив инженер, когото можем да получим. Дори ако един инженер е супер 10-кратен програмист, ако в крайна сметка той отблъсква много други инженери, които могат да работят по тестването, оптимизацията на производителността и т.н., просто не си струва да позволим на някого да бъде груб.
Източник: opennet.ru
