Desejo a todos um ótimo final de semana! Convidamos você para uma aula demo gratuita , conduzida por Andrey Buranov — especialista em sistemas UNIX da Mail.Ru Group. Publicamos também um artigo de Jonathan Corbet — Editor Executivo da LWN.net.
Sistemas de arquivos journaling prometem liberar administradores de sistema de problemas de corrupção de disco durante falhas do sistema. Mesmo sem executar verificações de integridade do sistema de arquivos. Embora, na realidade, tudo seja um pouco mais complicado. E como mostra uma discussão recente, pode ser até mais confuso do que muitos de nós pensamos, uma vez que a garantia de integridade dos sistemas de arquivos journaling afeta o desempenho.
Um sistema de arquivos como o ext3 utiliza uma área separada no disco, chamada de log. Ao fazer alterações nos metadados do sistema de arquivos, essas alterações são primeiro gravadas no log sem modificar o restante do sistema de arquivos. Após a gravação de todas as alterações no log, um ‘bloco de confirmação’ é adicionado, indicando a conclusão da transação. Somente após a gravação do bloco de confirmação é que a transação é finalizada e os metadados modificados são gravados no disco. Se o sistema falhar em algum momento, a informação no log permite um encerramento seguro, evitando a corrupção do sistema de arquivos devido ao fato de que apenas parte dos metadados foi atualizada.
No entanto, há um obstáculo: o código do sistema de arquivos deve ter certeza absoluta de que todas as informações da transação já foram registradas no log antes de gravar o bloco de confirmação. Simplesmente gravar operações na ordem correta não é suficiente — discos modernos suportam grandes caches internos e reordenam operações para melhorar o desempenho. Portanto, antes do bloco de confirmação, é necessário especificar explicitamente a transferência de todos os dados do log para o disco. Se o bloco de confirmação for gravado antes, o log pode ser corrompido. Para resolver esse problema, barreiras são utilizadas. Essencialmente, uma barreira proíbe a gravação de quaisquer blocos após a barreira até que todos os blocos gravados antes da barreira sejam transferidos para o disco. Ao usar barreiras, sistemas de arquivos garantem a coerência das estruturas de arquivos.
Mas há mais um problema: os sistemas de arquivos ext3 e ext4, por padrão, não utilizam barreiras. Existe uma opção, mas se o administrador não a ativar explicitamente, esses sistemas de arquivos funcionam sem barreiras, embora em algumas distribuições (como a SUSE) os valores padrão sejam diferentes. Eric Sandeen recentemente decidiu que essa situação precisava mudar e , modificando as configurações padrão para ext3 e ext4. E então começou uma discussão acalorada.
Andrew Morton respondeu , explicando por que o valor padrão é exatamente esse:
Na última vez em que tentamos alterar isso, o desempenho em muitas cargas caiu em 30%, então eu horrorizei e descartei todos esses patches. Eu acho que não podemos correr esse risco e reduzir a performance de todas as máquinas de forma tão significativa…
Não existem soluções ideais, e eu inclino-me a não perturbar esse cão adormecido e deixar os parâmetros padrão a critério dos desenvolvedores das distribuições.
Assim, por padrão, as barreiras estão desativadas, pois impactam seriamente o desempenho. Além disso, os sistemas de arquivos são utilizados com bastante sucesso sem barreiras. Os relatos de corrupção do sistema de arquivos ext3 são escassos e raros.
Mas isso não é apenas sorte. Ted Ts’o que o log do ext3 / ext4 geralmente é colocado de forma contínua. Em primeiro lugar, o driver do sistema de arquivos tenta criá-lo de forma contínua. Em segundo lugar, o log é geralmente criado ao mesmo tempo que o sistema de arquivos, quando é fácil encontrar espaço contínuo. A continuidade e a ordenação são úteis não apenas para o desempenho, mas também para evitar reordenação. Geralmente, o bloco de commit será colocado logo após os outros dados no log, portanto, o disco não tem motivos para reordenar. O bloco de commit é naturalmente gravado no disco logo após os outros registros do log.
No entanto, ninguém afirma que isso será sempre assim. Os discos podem se comportar de maneira diferente. Além disso, o log funciona como um buffer circular. Portanto, quando uma transação é gravada no final do log, o bloco de commit pode estar em um bloco anterior, antes de outras entradas do log. Assim, sempre há o risco de corrupção. Na verdade, Chris Mason tem testes sobre isso. . Não há dúvida de que trabalhar sem barreiras é menos seguro do que com elas.
Se você está disposto a aceitar um impacto no desempenho, pode ativar as barreiras. Claro, isso se sua sistema de arquivos não for baseado em LVM (como em algumas distribuições padrão). Ao que parece, o device mapper não suporta barreiras. Em outros casos, seria bom reduzir a perda de desempenho. E, aparentemente, isso pode ser feito.
A implementação atual do ext3 (quando as barreiras estão ativadas) realiza a seguinte sequência de operações para cada transação:
Os dados são gravados no log
Uma barreira é executada
O bloco de commit é gravado
A próxima barreira é executada
Mais tarde, os metadados são gravados no disco
No ext4, a primeira barreira (passo 2) pode ser pulada, pois o sistema de arquivos ext4 suporta somas de verificação no log.
Se os dados do log e o bloco de commit forem reordenados, e a operação for interrompida em consequência de uma falha, 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 "em geral seguro" remover essa barreira também no ext3, com a possível exceção de quando o log atinge o final e começa a escrever do início.
Outra ideia para acelerar o desempenho é adiar operações com barreiras, quando possível. Se não houver necessidade urgente de gravar os dados no disco imediatamente, é possível criar várias transações no log e gravá-las no disco com uma única barreira.
Além disso, há algum potencial para melhoria através da ordenação cuidadosa das operações, para que as barreiras (que geralmente são implementadas como solicitações "gravar todas as operações pendentes no disco") não forcem a gravação de blocos que não exigem uma ordem específica.
Parece que chegou a hora de pensar em como tornar o custo das barreiras aceitável. Ted Ts'o parece :
Acho que devemos incluir barreiras no ext3/4 e depois trabalhar na redução da sobrecarga no ext4/jbd2. Provavelmente, a grande maioria dos sistemas não opera em condições semelhantes às que Chris usou para demonstrar o problema, e a segurança do sistema de arquivos deve ser uma prioridade.
O bom senso me diz que esse cachorro já não está mais dormindo e provavelmente vai latir por um tempo. Isso pode causar preocupação em alguns vizinhos, mas é melhor do que deixá-lo morder.
Está interessado em desenvolver nesta direção? Inscreva-se para uma aula Demo gratuita e participe da transmissão , que será conduzida por Pavel Vikiryuk — operador de telecomunicações MVNO, engenheiro DevOps.
Fonte: habr.com
