Reflexões de Theodore Ts’o, criador do sistema de arquivos Ext4, sobre o desenvolvimento do ext4, do sistema de arquivos BcacheFS, do núcleo Linux, do ZFS, do código de conduta e dos sistemas de arquivos em geral:
Sobre o desenvolvimento do ext4.
Mais de uma dúzia de pessoas contribuem para cada lançamento do núcleo ext4. Atualmente, a maior parte do meu tempo é dedicada à revisão de código, à realização de testes e à melhoria do aplicativo de teste {kvm,gce,qemu,android}-xfstests. E eu conto bastante com 2-3 outros desenvolvedores que trabalham na SUSE e na IBM, que me ajudam na revisão de código.
Sobre o BcacheFS
Para ser honesto, bcachefs não é um projeto completamente independente — por exemplo, Kent foi o autor de 72% dos patches entre os lançamentos do núcleo 6.11 e 6.12, enquanto dos 103 patches para o ext4 no mesmo período, eu fui autor de exatamente 0%. Isso ocorre porque eu defendo firmemente que a programação é um esporte de equipe, e meu trabalho como líder técnico é capacitar os membros do ext4 a fazerem o possível para melhorar o sistema de arquivos. Realizamos conferências semanais, e Derrick Wong, desenvolvedor sênior do XFS e ex-mantenedor do XFS, participa dessas conferências — e, como é sabido, eu o ajudei com questões de teste do XFS, enquanto Derrick me ajudou com várias questões de teste do ext4 e até revisou alguns patches do ext4. Colaboramos uns com os outros, e isso é bom.
Eu deixo que as outras pessoas decidam se querem confiar seus dados a alguém que é um programador solitário, que pode ser mais talentoso do que eu, mas eu darei uma dica — você pode "trapacear", trazendo uma equipe para resolver o problema. Não é necessário fazer isso sozinho. Claro, para isso você precisa saber como despertar o melhor nos outros e deve trabalhar em conjunto. E um tratamento educado entre si nas listas de discussão não fará mal.
Sobre o núcleo, CoC, capacidades e o futuro do ext4
O Ext4 realmente está recebendo algumas novas funcionalidades, mas são aquelas que as empresas estão dispostas a financiar, porque o retorno sobre o investimento no desenvolvimento da funcionalidade faz sentido em termos de custos e benefícios. Por exemplo, o fscrypt e diretórios sem distinção entre maiúsculas e minúsculas eram funções úteis para o Android e o Chrome OS, e foram financiados, pelo menos em parte, por esses grupos de desenvolvedores (a Steam também se preocupou com a distinção entre maiúsculas e minúsculas e apoiou um dos engenheiros). Queremos adicionar suporte para gravação sem interrupções (untorn), pois isso melhorará o desempenho de bancos de dados em dispositivos de bloco emulados na nuvem, onde podemos garantir 16k de gravações atômicas, o que eliminará a necessidade de duplo buffering no MySQL e PostgreSQL.
(Na verdade, a Amazon e o Google podem fazer isso em seus próprios produtos de bancos de dados, fazendo suposições sobre como funcionam o Amazon EBS e o Google Persistent Disk, mas queremos fazer isso de uma forma mais geral, que será mais sustentável a longo prazo). Isso é menos atrativo do que coisas como reflinks, mas o retorno sobre o investimento é muito mais fácil de justificar, tanto pela redução de custos (menos trabalho de desenvolvimento, teste e qualificação para implementações corporativas) quanto porque os benefícios são muito mais fáceis de quantificar. Coisas como "posso economizar o custo salarial de XX engenheiros de software ao longo de cinco anos" são muito mais fáceis de fazer para esse tipo de funcionalidade de aumento de desempenho.
Em contraste, reflinks são interessantes, mas não consegui encontrar um cliente disposto a pagar os custos de desenvolvimento ou uma empresa que acredita que seus clientes comprariam mais de seu produto se adicionassem reflinks ao ext4. Isso pode parecer extremamente corporativo, mas há uma história sobre como engenheiros do ZFS começaram um projeto do zero, sem pedir permissão à gerência e sem receber sugestões do departamento de vendas, e apresentaram ao Sun o que na verdade era um fato consumado.
Isso soa bem, mas é importante lembrar que, no final, a Sun começou a perder dinheiro e foi forçada a se vender para outra empresa, e a organização de engenharia responsável pelo ZFS, na verdade, não existe mais. Cerca da mesma época em que o ZFS foi anunciado, participei de um estudo em toda a empresa para avaliar se fazia sentido investir em funcionalidades de sistema de arquivos para AIX e Linux — e concluímos que não, o retorno sobre o investimento era baixo, e novas funcionalidades de sistema de arquivos não levariam a um aumento no número de clientes adquirindo hardware, software ou sistemas da IBM. Talvez a IBM estivesse enfrentando tempos difíceis, mas ela ainda existe, enquanto a Sun não.
Cerca da mesma época, representantes de várias empresas de Linux se reuniram para discutir como o Linux competiria com o ZFS. Foi nessa reunião que surgiu a ideia de que o btrfs seria a resposta a longo prazo e que o ext4 seria uma solução de curto prazo, oferecendo suporte a recursos como redimensionamento em tempo real, números de bloco de 64 bits e outras funcionalidades que existiam nos sistemas operacionais Legacy Unix tradicionais e que não estavam presentes no ext3.
Durante essa reunião, fui solicitado a definir o que seria necessário para criar um sistema de arquivos completamente novo. Fiz uma pesquisa, analisando o quanto de esforço foi necessário para criar sistemas de arquivos como GPFS e JFS da IBM, advfs da Digital, e avaliei o quanto a Sun gastou para criar o ZFS e levar esse sistema de arquivos a um estado totalmente pronto para produção. A resposta que obtive foi de cerca de 100 anos-homem, com uma estimativa baixa de 50 anos-homem e uma alta de 200 anos-homem (mas isso foi para o GPFS, que era um sistema de arquivos em cluster e, portanto, muito mais complexo).
Informei isso na reunião, e um engenheiro sênior da Intel disse: 'Não, não diga isso aos gerentes, pois eles nunca aprovarão o projeto! Diga a eles que o btrfs estará pronto em 18 meses'. Deixo que as pessoas decidam por si mesmas quando o btrfs alcançará o status de 'pronto para uso corporativo', especialmente para essas novas funcionalidades avançadas atraentes que deveriam competir com o ZFS, mas não acho que seja discutível que isso não aconteceu em 18 meses.
E mesmo antes da Sun se desmembrar, muitas empresas que enviaram representantes para a reunião recusaram a participação de engenheiros no desenvolvimento do btrfs, e isso, claro, não ajudou. Mas, provavelmente, isso estava relacionado ao fato de que as empresas são organizações racionais que tomam suas próprias decisões sobre a rentabilidade dos investimentos, e financiar um novo sistema de arquivos não fazia tanto sentido quanto contar às pessoas que o Linux teria uma resposta ao ZFS.
Olhando para trás, pode-se dizer que, embora o ZFS tivesse esses recursos realmente legais, eles não eram suficientes para convencer a maioria dos usuários a escolher o Solaris em vez de comprar plataformas x86 muito mais baratas e instalar o Linux. E quando a Sun decidiu tentar a estratégia OpenSolaris e Solaris x86, já era tarde demais. Os efeitos de rede eram imensos, e a estratégia x86 não respondia à questão de como uma única empresa, a Sun, poderia pagar os salários de todos os engenheiros super talentosos que trabalhavam no Solaris. Comprar um servidor x86 por 5000 dólares não representa um grande retorno sobre o investimento em comparação com servidor um SunFire E10k Sparc por 100000 dólares, que a Sun chamava de "ponto" na "dot Com".
A questão é que a engenharia no mundo real é uma questão de compromissos, e as realidades de negócios fazem parte desse compromisso. Não me desculpo por preferir comer e por querer ganhar dinheiro suficiente para me aposentar algum dia. E isso, por sua vez, significa que eu preciso entender bem como trago valor ao meu empregador, pelo menos 10 vezes superior ao meu salário. Se eu conseguir fazer isso, continuando a trabalhar com código aberto e ajudando outras empresas a ganhar dinheiro, para que elas estejam dispostas a contribuir com o ext4, bem, isso faz parte do desafio e é o motivo pelo qual eu gosto de trabalhar com código aberto.
E, voltando ao Código de Conduta, posso dizer que quase todos os mantenedores dos sistemas de arquivos principais apoiaram o Código não por alguma razão liberal vaga. Isso porque precisamos de cada engenheiro disposto a contribuir para nosso projeto, e a maioria de nós viu pessoas que se recusaram a trabalhar no Linux e migraram para outros sistemas operacionais (conheço uma pessoa que se mudou para o Windows e era um valioso desenvolvedor do núcleo Linux no IBM Linux Technology Center) ou que trabalhavam em projetos internos, mas não em algo que exigia interação com o LKML, devido ao ambiente tóxico de algumas pessoas na lista de discussões.
Em alguns casos, as preocupações eram infundadas; por exemplo, Linus gritou com um desenvolvedor sênior que realmente deveria saber melhor e com quem Linus, na maioria das vezes, tinha um relacionamento pessoal estabelecido. O problema é que os novatos não sabiam disso e ficavam assustados — 'e se o Linus me humilhar em público como fez com o Steve', sem entender que na prática isso não aconteceria. É por isso que temos o CoC; não é para nós, engenheiros seniores, mas para apoiar os engenheiros mais jovens em nossas equipes, que queremos treinar para que, em algum momento, eles nos substituam quando chegar a hora de nos aposentarmos, ou um ônibus nos atropelar, ou de alguma forma deixarmos este mundo mortal.
Não se esqueça de 50-100 anos de trabalho na criação de um sistema de arquivos pronto para uso em um ambiente corporativo. Precisamos de todos os engenheiros que podemos atrair, e muitos de nós fazem trabalho extra em seu tempo livre porque nos importamos. Criar um sistema de arquivos de alta qualidade é um esforço em equipe, e precisamos de cada engenheiro talentoso que conseguimos recrutar. Mesmo que um engenheiro seja um programador excepcionalmente produtivo, se ele acabar afastando muitos outros engenheiros que podem trabalhar em testes, otimização de desempenho etc., simplesmente não vale a pena permitir que alguém seja um vilão.
Fonte: opennet.ru
