Um ótimo fim de semana a todos! Convidamos você para uma aula de demonstração gratuita , que será conduzido por Andrey Buranov, especialista em sistemas UNIX do Grupo Mail.Ru. Também publicamos um artigo de Jonathan Corbet – Editor Executivo no LWN.net.
Os sistemas de arquivos registrados prometem libertar os administradores de sistema do incômodo de corrupção de disco quando ocorrem falhas no sistema. Mesmo sem executar uma verificação de integridade do sistema de arquivos. Embora na realidade, claro, tudo seja um pouco mais complicado. E, como sugere uma discussão recente, pode ser ainda mais confuso do que muitos de nós pensamos, uma vez que garantir a integridade dos sistemas de arquivos registrados em diário tem implicações no desempenho.
Um sistema de arquivos como o ext3 usa uma área separada no disco chamada diário. Quando são feitas alterações nos metadados do sistema de arquivos, essas alterações são primeiro gravadas no diário sem modificar o restante do sistema de arquivos. Após todas as alterações serem gravadas no log, um “bloco de confirmação” é adicionado ao log, indicando a conclusão da transação. E somente depois que o bloco de commit for gravado, a transação será confirmada e os metadados alterados serão gravados no disco. Se o sistema travar em algum momento, você poderá usar as informações do log para desligar com segurança e evitar danos ao sistema de arquivos devido ao fato de apenas parte dos metadados ter sido atualizada.
Entretanto, há um problema: o código do sistema de arquivos deve ter certeza absoluta de que todas as informações sobre a transação já foram registradas antes de escrever um bloco de commit. Simplesmente registrar as operações na ordem correta não é suficiente: as unidades modernas mantêm grandes caches internos e reordenam as operações para melhorar o desempenho. Portanto, antes de confirmar um bloco, você deve especificar explicitamente que todos os dados de log serão transferidos para o disco. Se o bloco de confirmação for gravado anteriormente, o log poderá estar corrompido. Para resolver este problema, são utilizadas barreiras. Essencialmente, uma barreira impede que quaisquer blocos escritos após a barreira sejam gravados até que todos os blocos escritos antes da barreira tenham sido descarregados no disco. Ao usar barreiras, os sistemas de arquivos garantem a consistência das estruturas de arquivos.
Mas há outro problema: os sistemas de arquivos ext3 e ext4 não usam barreiras por padrão. Existe uma opção, mas a menos que o administrador os tenha ativado explicitamente, esses sistemas de arquivos funcionam sem barreiras, embora algumas distribuições (por exemplo, SUSE) tenham padrões diferentes. Eric Sandeen decidiu recentemente que esta situação precisava de mudar e , que modifica as configurações padrão para ext3 e ext4. E então começou uma discussão acalorada.
Andrew Morton (Andrew Morton) em grande detalhe por que o valor padrão é este:
A última vez que tentamos mudar isso, o desempenho foi degradado em 30% em muitas cargas de trabalho, então joguei fora todos aqueles patches, horrorizado. Não acho que possamos fazer isso e desacelerar tanto todas as máquinas...
Não existem soluções perfeitas aqui, e estou inclinado a não acordar esse cachorro adormecido e deixar as opções padrão ao critério dos desenvolvedores da distro.
Portanto, as barreiras são desativadas por padrão porque têm um sério impacto no desempenho. Além disso, os sistemas de arquivos podem ser usados com bastante sucesso e sem barreiras. Os relatórios de corrupção do sistema de arquivos ext3 são poucos e raros.
Mas não é apenas sorte. Ted Ts'o isso ocorre porque o log ext3/ext4 geralmente é contíguo. Primeiro, o driver do sistema de arquivos tenta torná-lo contíguo. Segundo, o diário geralmente é criado ao mesmo tempo que o sistema de arquivos, onde é fácil encontrar espaço contíguo. A continuidade e a ordem não são boas apenas para a produtividade, mas também para evitar novos pedidos. Normalmente, o bloco de confirmação será colocado imediatamente após o restante dos dados no log, portanto, não há motivo para reordenar o disco. O bloco de commit é naturalmente gravado no disco imediatamente após o restante das entradas de log.
No entanto, ninguém afirma que será sempre assim. As unidades de disco podem se comportar de maneira diferente. Além disso, o log é um buffer de anel. Portanto, quando uma transação é gravada no final do log, o bloco de commit pode terminar em um bloco anterior, antes de outras entradas do log. Portanto, sempre existe a possibilidade de danos. Na verdade, Chris Mason tem um para isso . Não há dúvida de que trabalhar sem barreiras é menos seguro do que com elas.
Se você estiver disposto a sofrer um impacto no desempenho, poderá ativar barreiras. A menos, é claro, que seu sistema de arquivos seja baseado em LVM (como é o caso de algumas distribuições por padrão). Acontece que o mapeador de dispositivos não suporta barreiras. Em outros casos, seria uma boa ideia reduzir a degradação do desempenho. E parece que isso pode ser feito.
A implementação atual do ext3 (quando as barreiras estão habilitadas) executa a seguinte sequência de operações para cada transação:
Os dados são registrados
Barreira em andamento
Um bloco de commit é escrito
A próxima barreira está sendo superada
Mais tarde, os metadados são descarregados no disco
No ext4, a primeira barreira (etapa 2) pode ser omitida porque o sistema de arquivos ext4 suporta somas de verificação de log.
Se os dados de log e o bloco de commit forem reordenados e a operação falhar, a soma de verificação do log não corresponderá àquela armazenada no bloco de commit e a transação será rejeitada.
Chris Mason , que seria “geralmente seguro” remover esta barreira no ext3, com a possível exceção de quando o log chega ao fim e começa a ser escrito desde o início.
Outra ideia para agilizar o trabalho é adiar as operações com barreiras sempre que possível. Se não houver necessidade urgente de liberar dados imediatamente para o disco, você poderá criar várias transações no log e liberá-los para o disco com uma barreira.
Há também algum potencial de melhoria ordenando cuidadosamente as operações para que as barreiras (que normalmente são implementadas como solicitações de "liberar todas as operações pendentes para o disco") não forcem gravações em blocos que não requerem ordenação.
Parece que é hora de pensar em como tornar o custo das barreiras acessível. Ted Tso, parece :
Acho que deveríamos ativar barreiras no ext3/4 e depois trabalhar para reduzir a sobrecarga no ext4/jbd2. É provável que a grande maioria dos sistemas não opere sob condições como as que Chris usou para demonstrar o problema, e a segurança do sistema de arquivos deveria ser uma prioridade por padrão.
O bom senso me diz que esse cachorro não está mais dormindo e provavelmente latirá por um tempo. Isso pode incomodar alguns vizinhos, mas é melhor do que deixá-la morder.
Você está interessado em se desenvolver nessa direção? Inscreva-se para uma aula de demonstração gratuita e participe da transmissão , que será conduzido por Pavel Vikiryuk - operador de telecomunicações MVNO, engenheiro DevOps.
Fonte: habr.com
