Aprenda o estado de desenvolvimento do Btrfs nessa entrevista com o principal autor, Chris Mason.
Swapnil Bhartiya
Chris Mason é o principal autor do Btrfs, o file system open source que é visto como o file system padrão do SUSE Enterprise Linux. Mason começou a trabalhar no Btrfs na Oracle e depois se mudou para o Facebook onde continua a trabalhar no file system como membro da equipe de Linux da empresa. Quando Facebook possui novos kernels que precisam ser lançados, Mason ajuda a certificar que tudo foi devidamente testado e encontra as necessidades de performance.
Sentamos com Mason para aprender mais sobre o status do Btrfs e como Facebook está utilizando Linux e o Btrfs. Aqui está uma versão editada dessa entrevista.
Linux.com: Btrfs anda sob desenvolvimento por muito tempo. Ele está pronto para uso em produção? Sei que as distribuições Linux estão utilizando-o como file system padrão, onde outras não.
Chris Mason: É de fato o padrão no SUSE Linux Enterprise Server. SUSE gasta um considerável montante de energia e de pessoa dando suporte ao Btrfs, que eu realmente aprecio. Red Hat não adotou do mesmo jeito. É uma dessas coisas onde pessoas pegam recursos que elas mais se importam e outras que elas querem construir em cima daquilo.
Linux.com: Quais são as áreas onde o Btrfs faz mais sentido? Se eu não estiver errado, Facebook também utiliza Btrfs?
Mason: Dentro do Facebook, novamente nós pegamos lugares alvos onde achamos que os recursos do Btrfs são realmente benefícios para a carga de trabalho em mãos. As grandes áreas que estamos tentando focar são tarefas de gerenciamento de sistemas, os tipos de coisas para se fazer snapshot.
Linux.com: Todos nós sabemos que Facebook é um usuário pesado de Linux. Dentro da massiva infraestrutura do Facebook, onde Linux está sendo utilizado?
Mason: O jeito mais fácil de descrever a infraestrutura no Facebook é que é bem tudo Linux. Os lugares que estamos murando para o Btrfs são realmente gerenciamento de tarefas em torno de distribuir o sistema operacional, distribuir atualizações rapidamente utilizando os recursos de snapshotting do Btrfs, utilizando os recursos checksumming do Btrfs e assim por diante. Também temos um número de máquinas rodando Gluster, utilizando ambos o XFS e o Btrfs. O alvo primário lá é armazenamento de dados. Uma das razões do porque eles gostam do Btrfs para o uso de Gluster use é por causa que o data CRCs (cyclic redundancy checks) e o metadata CRCs nos oferecem a habilidade de detectar problemas no hardware tal como corrupção silenciosa de dados no hardware. Encontramos na verdade poucos grande bugs de hardware com o Btrfs então ele tem sido beneficente para o Btrfs.
Linux.com: Enquanto estamos falando sobre Linux no Facebook, estou curioso o quão perto ou longe você está da mainline já que ninguém está utilizando o stock kernel; todos criam um fork menor como tweaks e tuning para uso próprio.
Mason: De um ponto de vista do Linux, nosso objetivo primário com o kernel Linux é rastrear a main line o máximo que podemos. Nosso objetivo é atualizar o kernel ao menos uma vez por ano. Estamos tentando mudar para um ciclo atualização com mais frequente do que essa. Temos uma primeira politica de upstream onde temos as alterações na mainline antes de utilizá-las. Se quisermos ter um recurso no kernel, ela tem que ir a mainline primeiro.
Linux.com: Por que vocês precisam de seu próprio fork?
Mason: É possível percorrer a mainline kernel. Você tem que ter algum tipo de fork, você refina as coisas, você ajusta as coisas, e você aplica alguns patches para seu próprio uso. Nosso objetivo e manter esse fork tão pequeno humanamente possível. Quando estamos mudando do kernel 4.0 para o 4.6, que estamos ainda em processo de mudança, eu estava realmente feliz quando fomos capazes de obter um desempenho de carga de trabalho em produção em par com apenas um patch. Esse foi realmente um grande negócio. Sendo capaz de pegar basicamente um kernel vanilla 4.6 e ter os mesmos desempenhos que tinhamos no nosso kernel 4.0 com nossos patches. E esse é realmente o nosso objetivo a longo prazo: Para nos aproximar cada vez mais a apenas ser capaz de rodar mailine, assim podemos fazer a transição de um kernel para outro muito rapidamente.
Linux.com: Todos nós temos visto máquinas rodando versões realmente antigas do kernel Linux, onde você está visando rodar a ultima versão se você puder. Qual a vantagem?
Mason: O maior benefício, como uma organização de engenharia, é que queremos contratar pessoas que estão fazendo upstream de coisas. Desenvolvedores querem trabalhar em tecnologias novas e inovadores, eles querem fazer seus trabalhos upstream, eles querem vir a essas conferências, e eles querem ser uma parte desta comunidade. Queremos ser capazes de ter nossos trabalhos no kernel em upstream e então trazê-lo de volta para o Facebook. É mais fácil encontrar e contratar desenvolvedores upstream, e é o melhor jeito de manter o fluxo de manutenção baixo.
Linux.com: No server space, nós com frequência escutamos de sysadmins que "uma vez que ele estiver instalado e rodando, não toque nele” que é contrário ao que vemos em infraestrutura de IT moderna onde o mantra aparenta mudar mais rápido para ficar mais seguro.
Mason: Acho que a escala do Facebook torna isso mais fácil para testarmos as coisas. Não é que o o trabalho de teste em si é mais fácil, mas podemos espalhar esse trabalho em um grande número de máquinas. Temos a habilidade levar o trabalho de teste para o que chamamos "Shadow Tiers." Nesses Shadow Tiers, podemos reproduzir o tráfego de produção em um ambiente de não produção real, assim podemos estar em um lugar muito seguro para verificar o desempenho e assegurar a estabilidade. Podemos construir uma rampa que trafega, assim posso iniciar e dizer, "Beleza, vou lhe dar 5 porcento de um replay do tráfego de produção e sobe tudo para 100 e observo o desempenho atual como eu me saio.” Pode obter uma comparação A/B muito forte entre os dois kernels ao longo do caminho. Temos as ferramentas para validar os kernels e ajudar a testar os kernels upstream. É mais fácil corrigir os novos e interessante bugs em upstream do que é constantemente apenas encontrar velhos bugs que o upstream já corrigiu.
Linux.com: Quais são as coisas que lhe deixam preocupado?
Mason: Em termos de rodar o Kernel Linux ou file systems, testamos tão bem e tanto suporte da comunidade em torno do Linux que eu realmente não me preocupo quanto a rodá-lo.
Linux.com: Você está envolvido com o Linux por muito tempo e Linux acabou de celebrar seu vigésimo quinto aniversário, o que você acha que Linux alcançou noesses 25 anos?
Mason: A parte que eu dou mais créditos ao Linus, a parte dos contribuidores técnicos que são óbvios, é sua habilidade de criar a comunidade do kernel de desenvolvedores onde as pessoas eram tão ativamente interessadas em levá-la adiante de verão para versão. Linux não fragmentou do jeito que muitos projetos já. Não é tudo o Linus, mas eu dou a Linus tanto crédito por que com o processo que ele definiu, foi muito mais fácil levar adiante com o kernel do que foi criar um fork dele e fazer algo mais diferente.
Acho que que é uma contribuição importante que um monte de pessoas negligencia em termos de como a comunidade do kernel se uniu e trouxe novas empresas ao invés de afastá-las.
Inicie o desenvolvimento do Linux. Confira a "Apresentação livre ao curso de desenvolvimento Open Source do Linux e o do GIT" da The Linux Foundation.
Chris Mason é o principal autor do Btrfs, o file system open source que é visto como o file system padrão do SUSE Enterprise Linux. Mason começou a trabalhar no Btrfs na Oracle e depois se mudou para o Facebook onde continua a trabalhar no file system como membro da equipe de Linux da empresa. Quando Facebook possui novos kernels que precisam ser lançados, Mason ajuda a certificar que tudo foi devidamente testado e encontra as necessidades de performance.
Sentamos com Mason para aprender mais sobre o status do Btrfs e como Facebook está utilizando Linux e o Btrfs. Aqui está uma versão editada dessa entrevista.
Linux.com: Btrfs anda sob desenvolvimento por muito tempo. Ele está pronto para uso em produção? Sei que as distribuições Linux estão utilizando-o como file system padrão, onde outras não.
Chris Mason: É de fato o padrão no SUSE Linux Enterprise Server. SUSE gasta um considerável montante de energia e de pessoa dando suporte ao Btrfs, que eu realmente aprecio. Red Hat não adotou do mesmo jeito. É uma dessas coisas onde pessoas pegam recursos que elas mais se importam e outras que elas querem construir em cima daquilo.
Linux.com: Quais são as áreas onde o Btrfs faz mais sentido? Se eu não estiver errado, Facebook também utiliza Btrfs?
Mason: Dentro do Facebook, novamente nós pegamos lugares alvos onde achamos que os recursos do Btrfs são realmente benefícios para a carga de trabalho em mãos. As grandes áreas que estamos tentando focar são tarefas de gerenciamento de sistemas, os tipos de coisas para se fazer snapshot.
Linux.com: Todos nós sabemos que Facebook é um usuário pesado de Linux. Dentro da massiva infraestrutura do Facebook, onde Linux está sendo utilizado?
Mason: O jeito mais fácil de descrever a infraestrutura no Facebook é que é bem tudo Linux. Os lugares que estamos murando para o Btrfs são realmente gerenciamento de tarefas em torno de distribuir o sistema operacional, distribuir atualizações rapidamente utilizando os recursos de snapshotting do Btrfs, utilizando os recursos checksumming do Btrfs e assim por diante. Também temos um número de máquinas rodando Gluster, utilizando ambos o XFS e o Btrfs. O alvo primário lá é armazenamento de dados. Uma das razões do porque eles gostam do Btrfs para o uso de Gluster use é por causa que o data CRCs (cyclic redundancy checks) e o metadata CRCs nos oferecem a habilidade de detectar problemas no hardware tal como corrupção silenciosa de dados no hardware. Encontramos na verdade poucos grande bugs de hardware com o Btrfs então ele tem sido beneficente para o Btrfs.
Linux.com: Enquanto estamos falando sobre Linux no Facebook, estou curioso o quão perto ou longe você está da mainline já que ninguém está utilizando o stock kernel; todos criam um fork menor como tweaks e tuning para uso próprio.
Mason: De um ponto de vista do Linux, nosso objetivo primário com o kernel Linux é rastrear a main line o máximo que podemos. Nosso objetivo é atualizar o kernel ao menos uma vez por ano. Estamos tentando mudar para um ciclo atualização com mais frequente do que essa. Temos uma primeira politica de upstream onde temos as alterações na mainline antes de utilizá-las. Se quisermos ter um recurso no kernel, ela tem que ir a mainline primeiro.
Linux.com: Por que vocês precisam de seu próprio fork?
Mason: É possível percorrer a mainline kernel. Você tem que ter algum tipo de fork, você refina as coisas, você ajusta as coisas, e você aplica alguns patches para seu próprio uso. Nosso objetivo e manter esse fork tão pequeno humanamente possível. Quando estamos mudando do kernel 4.0 para o 4.6, que estamos ainda em processo de mudança, eu estava realmente feliz quando fomos capazes de obter um desempenho de carga de trabalho em produção em par com apenas um patch. Esse foi realmente um grande negócio. Sendo capaz de pegar basicamente um kernel vanilla 4.6 e ter os mesmos desempenhos que tinhamos no nosso kernel 4.0 com nossos patches. E esse é realmente o nosso objetivo a longo prazo: Para nos aproximar cada vez mais a apenas ser capaz de rodar mailine, assim podemos fazer a transição de um kernel para outro muito rapidamente.
Linux.com: Todos nós temos visto máquinas rodando versões realmente antigas do kernel Linux, onde você está visando rodar a ultima versão se você puder. Qual a vantagem?
Mason: O maior benefício, como uma organização de engenharia, é que queremos contratar pessoas que estão fazendo upstream de coisas. Desenvolvedores querem trabalhar em tecnologias novas e inovadores, eles querem fazer seus trabalhos upstream, eles querem vir a essas conferências, e eles querem ser uma parte desta comunidade. Queremos ser capazes de ter nossos trabalhos no kernel em upstream e então trazê-lo de volta para o Facebook. É mais fácil encontrar e contratar desenvolvedores upstream, e é o melhor jeito de manter o fluxo de manutenção baixo.
Linux.com: No server space, nós com frequência escutamos de sysadmins que "uma vez que ele estiver instalado e rodando, não toque nele” que é contrário ao que vemos em infraestrutura de IT moderna onde o mantra aparenta mudar mais rápido para ficar mais seguro.
Mason: Acho que a escala do Facebook torna isso mais fácil para testarmos as coisas. Não é que o o trabalho de teste em si é mais fácil, mas podemos espalhar esse trabalho em um grande número de máquinas. Temos a habilidade levar o trabalho de teste para o que chamamos "Shadow Tiers." Nesses Shadow Tiers, podemos reproduzir o tráfego de produção em um ambiente de não produção real, assim podemos estar em um lugar muito seguro para verificar o desempenho e assegurar a estabilidade. Podemos construir uma rampa que trafega, assim posso iniciar e dizer, "Beleza, vou lhe dar 5 porcento de um replay do tráfego de produção e sobe tudo para 100 e observo o desempenho atual como eu me saio.” Pode obter uma comparação A/B muito forte entre os dois kernels ao longo do caminho. Temos as ferramentas para validar os kernels e ajudar a testar os kernels upstream. É mais fácil corrigir os novos e interessante bugs em upstream do que é constantemente apenas encontrar velhos bugs que o upstream já corrigiu.
Linux.com: Quais são as coisas que lhe deixam preocupado?
Mason: Em termos de rodar o Kernel Linux ou file systems, testamos tão bem e tanto suporte da comunidade em torno do Linux que eu realmente não me preocupo quanto a rodá-lo.
Linux.com: Você está envolvido com o Linux por muito tempo e Linux acabou de celebrar seu vigésimo quinto aniversário, o que você acha que Linux alcançou noesses 25 anos?
Mason: A parte que eu dou mais créditos ao Linus, a parte dos contribuidores técnicos que são óbvios, é sua habilidade de criar a comunidade do kernel de desenvolvedores onde as pessoas eram tão ativamente interessadas em levá-la adiante de verão para versão. Linux não fragmentou do jeito que muitos projetos já. Não é tudo o Linus, mas eu dou a Linus tanto crédito por que com o processo que ele definiu, foi muito mais fácil levar adiante com o kernel do que foi criar um fork dele e fazer algo mais diferente.
Acho que que é uma contribuição importante que um monte de pessoas negligencia em termos de como a comunidade do kernel se uniu e trouxe novas empresas ao invés de afastá-las.
Inicie o desenvolvimento do Linux. Confira a "Apresentação livre ao curso de desenvolvimento Open Source do Linux e o do GIT" da The Linux Foundation.
Nenhum comentário:
Postar um comentário
Viu algum erro e quer compartilhar seu conhecimento? então comente aí.
Observação: somente um membro deste blog pode postar um comentário.