É sabido que você nunca deve fsck uma partição montada. Eu posso entender como isso pode facilmente levar à corrupção se o sistema de arquivos for gravado pelo fsck (por exemplo, a opção -a é usada), mas por que as verificações somente leitura não podem ser executadas em discos montados?
Respostas:
De:
http://linux.die.net/man/8/fsck.ext3
"Note-se que, em geral, não é seguro para ser executado e2fsckem sistemas de arquivos montados. A única exceção é se a -nopção for especificada, e -c, -lou -Lopções não são especificados. No entanto, mesmo que seja seguro fazê-lo, os resultados impressos pelo e2fscksão não é válido se o sistema de arquivos estiver montado. Se e2fsckperguntar se você deve ou não verificar um sistema de arquivos montado, a única resposta correta é '' não ''. Somente especialistas que realmente sabem o que estão fazendo devem considerar responder a essa pergunta em qualquer outro maneira. "
O problema básico é que o verificador do sistema de arquivos (geralmente) não faz parte do sistema de arquivos. Em vez disso, é um programa separado que lê e grava no mesmo disco que o código do sistema de arquivos no kernel. Como resultado, se você executar o fsck em um sistema de arquivos ativo, terá duas entidades diferentes que estão lendo (e potencialmente modificando) os mesmos dados (o disco), mas elas não estão se coordenando de forma alguma. O resultado, como outros salientaram, é que a maioria dos verificadores espera que ninguém mais esteja alterando os metadados do sistema de arquivos enquanto executam. Eles ficarão confusos e / ou reportarão erros espúrios se o sistema de arquivos do kernel mudar algo que o verificador não espera.
Existem alguns sistemas de arquivos com verificadores projetados explicitamente para serem executados "on-line" (ou seja, enquanto o sistema de arquivos estiver ativo). As versões mais recentes do FFS / UFS fazem isso executando o fsck em uma captura instantânea recente do sistema de arquivos (uma réplica somente leitura, point-in-time, cópia na gravação). Se encontrar problemas, como inconsistências nos mapas de bits de alocação, os corrigirá via chamada do sistema, em vez de gravar no disco bruto. Isso permite coordenar com o sistema de arquivos ativo.
O WAFL da NetApp também possui uma ferramenta de verificação on-line. Provavelmente existem outros.
A execução do fsck em uma leitura e gravação montada em partição seria tola, mesmo com o fsck no modo somente leitura. O sistema de arquivos mudará sob fsck, e os dados na memória que o fsck armazena em cache no sistema de arquivos se tornarão inválidos (e, portanto, o fsck verá inconsistência). Você pode executar o fsck em um sistema de arquivos montado somente leitura no modo somente leitura e obter resultados válidos. A execução do fsck no modo de leitura / gravação em um sistema de arquivos montado somente leitura, se o fsck fizer alterações no sistema de arquivos durante a execução, faria com que o kernel visse as estruturas do sistema de arquivos mudando inesperadamente sob ele. Isso também seria ruim.
Além do fato de que provavelmente mataria sua taxa de transferência de E / S, se o sistema de arquivos estiver sendo modificado enquanto estiver sendo fsck, não há como o fsck acompanhar as alterações e reportar inconstâncias.
Alguns sistemas de arquivos como o XFS permitem executar a verificação de consistência enquanto o sistema de arquivos é montado como leitura / gravação, com a ressalva de que erros espúrios provavelmente serão relatados. xfs_checkrecomenda que o sistema de arquivos seja desmontado ou montado somente leitura antes de executar a verificação.
Bem, o objetivo do fsck é relatar inconsistências do sistema de arquivos, que são violadas invariantes.
No entanto, muitas dessas verificações envolvem mais de uma estrutura de FS. Se alguém estiver modificando o FS (gravação de dados), essas estruturas podem estar temporariamente fora de sincronia. O fsck consideraria isso uma inconsistência, mesmo que não seja realmente um problema. O fsck não tem como saber se uma inconsistência é apenas temporária ou se é um problema permanente que precisa ser corrigido. Portanto, isso não pode funcionar (a menos que um FS seja projetado especificamente para permitir a verificação on-line. Alguns o fazem, mas o ext3 não).
Você pode, assim como enfiar a mão em um liquidificador em movimento e possivelmente não se machucar, ou assim como pode pular de um prédio alto enquanto aponta para a pequena pilha de almofadas que você colocou na calçada abaixo.
Mas por que você, além de testar sua própria mortalidade? Porque seu chefe certamente testará novamente quando descobrir POR QUE o servidor de correio não reconhecerá a unidade raiz agora.