Notei que o XFS não implementa um fsck na inicialização do sistema e um dos motivos apontados nos sistemas de arquivos com registro em diário ajuda a garantir que o sistema de arquivos esteja em um estado consistente após um desligamento impuro; na próxima montagem (por exemplo, após a reinicialização), o diário é repetido.
Um fsck ainda é necessário após um desligamento imundo e por quê?
Estou respondendo a isso no contexto geral de "sistemas de arquivos diários".
Eu acho que se você fizesse vários "desligamentos impuros" ( puxando o cabo de força ou algo assim ) mais cedo ou mais tarde, chegaria a um estado de sistema de arquivos que exigiria fsckou o equivalente moral de fsck xfs_repair,. A ext4maioria dos arquivos no meu laptop apenas reproduz o diário em todas as reinicializações, incluindo desligamentos limpos, mas, de vez em quando, ele faz tudo fsck.
Mas pergunte a si mesmo o que "repetir o diário" realiza. A reprodução de um diário apenas garante que os blocos de disco do restante do sistema de arquivos correspondam à ordem exigida pelas entradas do diário. A reprodução de um diário equivale a um pequeno fsckou a partes inteiras fsck.
Eu acho que há algum truque verbal: repetir um diário faz parte do que é tradicional fscke xfs_repairé exatamente o mesmo tipo de programa que e2fs.fsck(ou qualquer outro sistema de arquivos fsck). O pessoal do XFS simplesmente acreditou ou sua experiência levou-os a não rodar xfs_repairem todas as inicialização, apenas a repetir o diário.
fscknão é "pedante". Eu converti umaext3LVMpartiçãoext4e comecei a receber erros 'ext4_mb_generate_buddy' devido, como eu entendo, a um erro noext4código que causava uma incompatibilidade nas cópias em disco e na memória do bitmap nas partições 'LVM' convertidas. Até onde eu seifsck, nenhuma corrupção ocorreu. A solução foi desativar aUNINIT_BGopção ou mover os dados e reinicializar a partição comoext4; Eu fiz o último curso. Mas ainda acho que alguns minutos esperando por umfsckvale a pena não perder dados!A primeira coisa a se notar é que o XFS, o reiser e a maioria das configurações do ext implementam apenas o diário de meta-dados, que consiste em evitar o fsck. O diário nem sempre é reproduzido na inicialização - ele pode ser descartado se estiver incompleto.
Existem sistemas que suportam o diário completo de dados - mas, na prática, o nível de garantia que eles fornecem apenas o diário de meta-dados é muito pequeno em cenários do mundo real.
Portanto, um 'estado inconsistente' e os problemas corrigidos pelo fsck são incompatíveis entre os metadados e os próprios arquivos. Para evitar isso, o sistema operacional grava as alterações de metadados propostas no diário, depois grava os dados reais no disco e aplica as alterações de metadados que são replicadas no diário no disco. O único problema é que o controlador de disco armazenará em buffer e potencialmente reordenará as solicitações. Para evitar isso, a maioria dos sistemas de arquivos diários implementa barreiras: eles separam cada operação e esperam que o disco reconheça que concluiu a operação. Mas muitos discos modernos realmente reconhecem a conclusão das gravações antes dos dados serem confirmados. Portanto, as coisas podem ficar confusas.
A maioria dos sistemas de arquivos mantém uma contagem de montagem - uma vez que essa contagem é atingida, um fsck completo será acionado na próxima tentativa de montar o disco. O motivo é que os dados do disco podem ser corrompidos mesmo quando não estão sendo gravados explicitamente, mesmo sem erros no software. O comentário de psusi acima está errado.
fonte
hdparm -W), o disco não concluirá as solicitações de gravação até que esteja na mídia. Por que você acha que essa opção existe? As barreiras impedem a reordenação quando várias solicitações são emitidas. Sem barreiras, o fs simplesmente não emite mais solicitações até que as anteriores sejam concluídas, mantendo assim a ordem sem barreiras ... desde que o cache de gravação em disco não esteja ativado. O objetivo das barreiras é permitir que você ative o cache de gravação, sem danificar o fs em uma falha.sync. Deixe-me tentar de novo. O procedimento para gravar no disco sem barreiras é gravar no diário,syncliberando todos os caches de gravação e gravando os dados reais. Isso garante que o diário sempre possa ser usado para recuperar o fs após uma falha, mas a sincronização diminui a velocidade e derrota pela metade o objetivo do cache de gravação. Assim, as barreiras foram adicionadas como uma melhor substituição esync, com o suporte adequado ao disco, elas podem recuperar com segurança grande parte do desempenho que a sincronização retira.Não é necessário fsckar um sistema de arquivos de registro em diário simplesmente por causa de um desligamento imundo.
O toda razão para suportar a pena de journaling metadados desempenho de tempo de execução é assegurar que o sistema de arquivos pode ser feita 100% consistente novamente, repetindo automaticamente o registo de metadados na próxima montagem, se o sistema de arquivos não era limpa desmontado.
A única função do fsck é garantir a consistência dos metadados, por isso é redundante executar o fsck simplesmente porque o sistema de arquivos não foi desmontado corretamente.
Um sistema de arquivos de registro no diário pode ser corrompido por outros motivos - falha de hardware, erros de driver, erros de administrador etc. -, portanto, as ferramentas fsck são certamente necessárias. Não há razão para invocá-los apenas devido a um desligamento imundo.
fonte