Размисли на Теодор Ц’о (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 започна да губи пари, докато не беше принудена да се продаде на друга компания, и всъщност инженерната организация, поддържаща ZFS, вече не съществува. Около времето, когато беше анонсиран ZFS, участвах в проучване в цялата компания относно това, има ли смисъл да се инвестират в файлови системи за AIX и Linux — и стигнахме до извода, че не, възвръщаемостта на инвестициите е малка, а новите функции на файловите системи няма да доведат до увеличаване на броя на клиентите, купуващи оборудване, софтуер или системи IBM. Може би за IBM настъпиха трудни времена, но тя все още съществува, а Sun — не.
Около същото време представители на няколко Linux компании се събраха, за да измислят как Linux ще конкурира с ZFS. Именно на тази среща бе изказана идеята, че btrfs ще бъде дългосрочното решение, а ext4 — краткосрочното решение, което ще осигури поддръжка на неща като промяна на размера в реално време, 64-битови номера на блокове и други неща, които бяха в традиционните Legacy Unix операционни системи и които липсваха в 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
