Reflex\u00f5es de Theodore Ts'o, criador do sistema de arquivos Ext4, sobre o desenvolvimento do ext4, o sistema de arquivos BcacheFS, o n\u00facleo do Linux, ZFS, o c\u00f3digo de conduta e sistemas de arquivos em geral: <\/p>\n
Sobre o desenvolvimento do ext4<\/b>. <\/p>\n Mais de uma d\u00fazia de pessoas contribuem para cada lan\u00e7amento do n\u00facleo ext4. Atualmente, a maior parte do meu tempo \u00e9 dedicada \u00e0 revis\u00e3o de c\u00f3digo, \u00e0 realiza\u00e7\u00e3o de testes e \u00e0 melhoria do aplicativo de teste {kvm<\/a>,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\u00e3o de c\u00f3digo. <\/p><\/blockquote>\n Sobre o BcacheFS<\/b> <\/p>\n Para ser sincero, o bcachefs n\u00e3o \u00e9 um projeto completamente solit\u00e1rio \u2014 por exemplo, Kent foi o autor de 72% dos patches entre as vers\u00f5es do n\u00facleo 6.11 e 6.12, enquanto dos 103 patches para o ext4 no mesmo per\u00edodo, eu fui o autor de exatamente 0%. Isso porque sou firme na cren\u00e7a de que a programa\u00e7\u00e3o \u00e9 um esporte em equipe, e meu papel como l\u00edder t\u00e9cnico \u00e9 capacitar os participantes do ext4 a fazer o seu melhor para melhorar o sistema de arquivos. Realizamos confer\u00eancias semanais, e Derrick Wong, desenvolvedor s\u00eanior do XFS e ex-mantenedor do XFS, participa dessas confer\u00eancias \u2014 e eu, como \u00e9 sabido, o ajudei com quest\u00f5es de teste do XFS, e Derrick me ajudou em v\u00e1rias quest\u00f5es de teste do ext4 e at\u00e9 revisou alguns patches do ext4. Colaboramos um com o outro, e isso \u00e9 bom. <\/p>\n Eu deixo que outras pessoas decidam se querem confiar seus dados a algu\u00e9m que \u00e9 um programador solit\u00e1rio e que pode ser mais talentoso do que eu, mas eu lhes darei uma dica \u2014 voc\u00ea pode 'enganar' reunindo uma equipe para resolver o problema. N\u00e3o \u00e9 necess\u00e1rio fazer isso sozinho. Claro, para isso voc\u00ea precisa saber como despertar o melhor nos outros, e deve trabalhar em conjunto. E um trato educado entre si nas listas de discuss\u00e3o n\u00e3o far\u00e1 mal. <\/p><\/blockquote>\n Sobre o n\u00facleo, CoC, capacidades e o futuro do ext4<\/b> <\/p>\n O Ext4 realmente est\u00e1 recebendo algumas novas funcionalidades, mas s\u00e3o aquelas que as empresas est\u00e3o dispostas a financiar, porque o retorno sobre o investimento no desenvolvimento da funcionalidade faz sentido em termos de custos e benef\u00edcios. Por exemplo, o fscrypt e diret\u00f3rios sem distin\u00e7\u00e3o entre mai\u00fasculas e min\u00fasculas eram fun\u00e7\u00f5es \u00fateis para o Android e o Chrome OS, e foram financiados, pelo menos em parte, por esses grupos de desenvolvedores (a Steam tamb\u00e9m se preocupou com a distin\u00e7\u00e3o entre mai\u00fasculas e min\u00fasculas e apoiou um dos engenheiros). Queremos adicionar suporte para grava\u00e7\u00e3o sem interrup\u00e7\u00f5es (untorn), pois isso melhorar\u00e1 o desempenho de bancos de dados em dispositivos de bloco emulados na nuvem, onde podemos garantir 16k de grava\u00e7\u00f5es at\u00f4micas, o que eliminar\u00e1 a necessidade de duplo buffering no MySQL e PostgreSQL. <\/p>\n (Na verdade, a Amazon e o Google podem fazer isso em seus pr\u00f3prios produtos de SGBD, fazendo suposi\u00e7\u00f5es sobre como funcionam o Amazon EBS e o Google Persistent Disk, mas queremos fazer isso de uma maneira mais geral, que seja mais sustent\u00e1vel a longo prazo). Isso \u00e9 menos atraente do que coisas como reflinks, mas o retorno sobre o investimento \u00e9 muito mais f\u00e1cil de justificar, tanto porque os custos s\u00e3o mais baixos (menos trabalho de desenvolvimento, teste e qualifica\u00e7\u00e3o para implanta\u00e7\u00e3o corporativa), quanto porque os benef\u00edcios s\u00e3o muito mais f\u00e1ceis de quantificar. Coisas como 'posso economizar o custo do sal\u00e1rio de XX engenheiros-programadores durante cinco anos' s\u00e3o muito mais f\u00e1ceis de fazer para esse tipo de fun\u00e7\u00e3o de aumento de desempenho. <\/p>\n Diferente disso, reflinks \u2014 \u00e9 divertido, mas n\u00e3o consegui encontrar um cliente disposto a arcar com os custos de desenvolvimento, ou uma empresa que acredita que seus clientes comprar\u00e3o mais de seu produto se adicionarem reflinks ao ext4. Isso pode parecer incrivelmente corporativo, mas h\u00e1 uma hist\u00f3ria sobre como engenheiros do ZFS come\u00e7aram um projeto do zero, sem pedir permiss\u00e3o \u00e0 gest\u00e3o e sem receber sugest\u00f5es do departamento de vendas, e apresentaram \u00e0 Sun o que na verdade j\u00e1 era um fato consumado. <\/p>\n Parece incr\u00edvel, mas se lembrarmos que, no final, a Sun come\u00e7ou a perder dinheiro at\u00e9 ser for\u00e7ada a se vender a outra empresa, e que na verdade a organiza\u00e7\u00e3o de engenharia que apoiava o ZFS j\u00e1 n\u00e3o existe mais. Por volta da \u00e9poca em que o ZFS foi anunciado, participei de um estudo em toda a empresa sobre se fazia sentido investir em recursos de sistema de arquivos para AIX e Linux \u2014 e chegamos \u00e0 conclus\u00e3o de que n\u00e3o, o retorno sobre o investimento era baixo, e os novos recursos de sistema de arquivos n\u00e3o levariam a um aumento no n\u00famero de clientes comprando hardware, software ou sistemas IBM. Talvez a IBM estivesse passando por tempos dif\u00edceis, mas ainda existe, enquanto a Sun n\u00e3o. <\/p>\n Mais ou menos ao mesmo tempo, representantes de v\u00e1rias empresas de Linux se reuniram para pensar em como o Linux iria competir com o ZFS. Foi nessa reuni\u00e3o que surgiu a ideia de que o btrfs seria a resposta a longo prazo, enquanto o ext4 seria uma solu\u00e7\u00e3o a curto prazo que garantiria suporte para coisas como redimensionamento em tempo real, n\u00fameros de bloco de 64 bits e outras coisas que estavam nos tradicionais sistemas operacionais Unix legados e que n\u00e3o existiam no ext3. <\/p>\n Durante essa reuni\u00e3o, fui solicitado a definir o que seria necess\u00e1rio para criar um sistema de arquivos completamente novo. Fiz uma pesquisa, analisando o quanto de esfor\u00e7o foi necess\u00e1rio 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\u00e7\u00e3o. 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). <\/p>\n Eu relatei isso na reuni\u00e3o, e um engenheiro s\u00eanior da Intel disse: 'N\u00e3o, n\u00e3o conte isso aos diretores, porque eles nunca aprovar\u00e3o o projeto! Diga a eles que o btrfs estar\u00e1 pronto em 18 meses'. Eu deixo as pessoas decidirem quando o btrfs alcan\u00e7ar\u00e1 o status de 'pronto para uso corporativo', especialmente para aqueles novos recursos estendidos atraentes que deveriam competir com o ZFS, mas n\u00e3o penso que seja discut\u00edvel que isso n\u00e3o aconteceu em 18 meses. <\/p>\n E antes mesmo da Sun se desfazer, muitas empresas, que enviaram seus representantes para a reuni\u00e3o, se recusaram a permitir a participa\u00e7\u00e3o de engenheiros no trabalho do btrfs, e isso, \u00e9 claro, n\u00e3o ajudou. Mas, provavelmente, isso estava relacionado ao fato de que as empresas \u2014 organiza\u00e7\u00f5es racionais que tomam suas pr\u00f3prias decis\u00f5es sobre a viabilidade do investimento \u2014 consideraram que financiar um novo sistema de arquivos n\u00e3o fazia tanto sentido quanto contar \u00e0s pessoas que o Linux teria uma resposta para o ZFS. <\/p>\n Olhando para tr\u00e1s, pode-se dizer que, embora o ZFS tivesse esses recursos realmente legais, eles n\u00e3o eram suficientes para convencer a maioria dos usu\u00e1rios 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\u00e9gia OpenSolaris e Solaris x86, j\u00e1 era tarde demais. Os efeitos de rede eram imensos, e a estrat\u00e9gia x86 n\u00e3o respondia \u00e0 quest\u00e3o de como uma \u00fanica empresa, a Sun, poderia pagar os sal\u00e1rios de todos os engenheiros super talentosos que trabalhavam no Solaris. Comprar um servidor x86 por 5000 d\u00f3lares n\u00e3o representa um grande retorno sobre o investimento em compara\u00e7\u00e3o com servidor<\/a> SunFire E10k Sparc por 100000 d\u00f3lares, que a Sun chamava de \"ponto\" na \"dot Com\". <\/p>\n O ponto \u00e9 que a atividade de engenharia no mundo real \u00e9 um compromisso, e as realidades de neg\u00f3cios fazem parte desse compromisso. N\u00e3o me desculpo por preferir comer e por querer ganhar o suficiente para me aposentar um dia. E isso, por sua vez, significa que eu preciso entender bem como eu trago valor ao meu empregador, pelo menos 10 vezes o meu sal\u00e1rio. Se eu conseguir fazer isso, continuando a trabalhar com c\u00f3digo aberto e ajudando outras empresas a ganhar dinheiro para que estejam prontas para contribuir com o ext4, bem, essa \u00e9 parte do desafio e \u00e9 por isso que adoro trabalhar com c\u00f3digo aberto. <\/p>\n E, voltando ao C\u00f3digo de Conduta, posso dizer que quase todos os mantenedores dos sistemas de arquivos principais apoiaram o C\u00f3digo n\u00e3o por alguma raz\u00e3o liberal vaga. Isso porque precisamos de cada engenheiro disposto a contribuir para nosso projeto, e a maioria de n\u00f3s viu pessoas que se recusaram a trabalhar no Linux e migraram para outros sistemas operacionais (conhe\u00e7o uma pessoa que se mudou para o Windows e era um valioso desenvolvedor do n\u00facleo Linux no IBM Linux Technology Center) ou que trabalhavam em projetos internos, mas n\u00e3o em algo que exigia intera\u00e7\u00e3o com o LKML, devido ao ambiente t\u00f3xico de algumas pessoas na lista de discuss\u00f5es. <\/p>\n Em alguns casos, as preocupa\u00e7\u00f5es eram infundadas; por exemplo, Linus lan\u00e7ou um grito contra um desenvolvedor s\u00eanior que realmente deveria saber melhor e com quem Linus j\u00e1 tinha um relacionamento pessoal na maioria das vezes. O problema \u00e9 que os novatos n\u00e3o sabiam disso e ficavam assustados \u2014 \"e se Linus me humilhar em p\u00fablico como fez com Steve?\", sem entender que, na pr\u00e1tica, isso n\u00e3o aconteceria. \u00c9 por isso que temos um CoC; n\u00e3o \u00e9 para n\u00f3s, engenheiros s\u00eaniores, mas para apoiar os engenheiros mais jovens em nossas equipes, que queremos treinar para que um dia nos substituam, quando chegar a hora de nos aposentarmos, ou sermos atropelados por um \u00f4nibus, ou de outra forma deixarmos este mundo ef\u00eamero. <\/p>\n N\u00e3o se esque\u00e7a do trabalho de 50 a 100 anos de homem para criar um sistema de arquivos pronto para uso em ambientes corporativos. Precisamos de todos os engenheiros que pudermos atrair, e muitos de n\u00f3s fazem trabalho extra em seu tempo livre porque nos importamos. Criar um sistema de arquivos de alta qualidade \u00e9 um esfor\u00e7o em equipe e precisamos de cada engenheiro talentoso que possamos conseguir. Mesmo que um engenheiro seja um programador super 10x, se ele afastar uma s\u00e9rie de outros engenheiros que poderiam trabalhar em testes, afina\u00e7\u00e3o de desempenho, etc., simplesmente n\u00e3o vale a pena permitir que algu\u00e9m seja um vil\u00e3o. <\/p><\/blockquote>\n\n
\n
\n