!Ъ: https://www.opennet.ru/opennews/art.shtml?num=62597
Ъ:
Перевод размышлений Теодора Тс’о (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. Мы сотрудничаем друг с другом, и это замечательно.
Я предоставляю другим людям право решать, стоит ли им доверить свои данные кому-то, кто является одиноким крутым программистом, который вполне может быть более талантливым, чем я, но я дам вам подсказку - вы можете «сжульничать» и привлечь команду к решению проблемы. Не обязательно всё делать в одиночку. Конечно, для этого вам нужно знать, как пробудить лучшее в других, и вы должны работать вместе. И вежливое отношение друг к другу в списках рассылки не помешает.
О ядре, 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 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-кратный программист, если в итоге он отпугнёт кучу других инженеров, которые могут работать над тестированием, настройкой производительности и т.д., это просто не стоит того, чтобы позволить кому-то быть мерзавцем.
