Перевод размышлений Теодора Тс'о (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, а я был автором ровно 0% из 103 патчей к ext4 за тот же период времени. Это потому, что я твёрдо придерживаюсь мнения, что программирование - командный вид спорта, и моя работа как технического руководителя заключается в том, чтобы предоставить участникам разработки ext4 все возможности для улучшения файловой системы. Мы проводим еженедельные конференции, и Дэррик Вонг, старший разработчик XFS и бывший сопровождающий XFS, принимает участие в этих конференциях. Я, как известно, помогал ему в вопросах тестирования XFS, а Дэррик помогал мне в различных вопросах тестирования ext4 и даже рассмотрел пару патчей ext4. Мы сотрудничаем друг с другом, и это замечательно.

Я предоставляю другим людям право решать, стоит ли им доверить свои данные кому-то, кто является одиноким крутым программистом, который вполне может быть более талантливым, чем я, но я дам вам подсказку - вы можете «сжульничать» и привлечь команду к решению проблемы. Не обязательно всё делать в одиночку. Конечно, для этого вам нужно знать, как пробудить лучшее в других, и вы должны работать вместе. И вежливое отношение друг к другу в списках рассылки не помешает.

О ядре, кодексе поведения, возможностях и будущем 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, я участвовал в корпоративном исследовании целесообразности инвестирования IBM в развитие функциональности файловой системы для 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) или работали над внутренними проектами, но не над тем, что требовало взаимодействия в списке рассылки разработчиков ядра.

В некоторых случаях опасения были необоснованными; например, Линус кричал на разработчика, которому не следовало лезть на рожон и с которым Линус был знаком лично, и у них были уже сложившиеся взаимоотношения. Проблема в том, что новички не знали этого и пугались - «а вдруг Линус унизит меня на публике так же, как он поступил со Стивом», не понимая, что на практике этого не произойдёт. Вот почему у нас есть CoC; это не для нас, старших инженеров, а для поддержки более молодых инженеров в наших командах, которых мы хотим обучать, чтобы они в какой-то момент заменили нас, когда придёт время уходить на пенсию, или нас собьёт автобус, или мы иным образом покинем этот бренный мир.

Не забывайте о 50-100 человеко-лет работы над созданием файловой системы, готовой к использованию в корпоративной среде. Нам нужны все инженеры, которых мы можем привлечь, и многие из нас выполняют дополнительную работу в свободное время, потому что нам не все равно. Создание высококачественной файловой системы - это командная работа, и нам нужен каждый талантливый инженер, которого мы можем заполучить. Даже если один инженер - супер программист, работающий за десятерых, но он в итоге отпугивает кучу других инженеров, которые могли бы работать над тестированием, настройкой производительности и другими задачами, то это просто не стоит того, чтобы терпеть присутствие мерзавца.