Por que você não pode fsck uma partição montada?

38

É bem conhecido que você nunca deve fsck uma partição montada. Eu posso entender como isso poderia facilmente levar a corrupção se o sistema de arquivos é escrito para por fsck (por exemplo, a opção -a é usada), mas por que verificações somente leitura podem ser executadas em discos montados ?

    
por mike 22.06.2009 / 20:06

7 respostas

25

De:

link

"Note que em geral não é seguro executar o e2fsck em sistemas de arquivos montados. A única exceção é se a opção -n for especificada e as opções -c, -l ou -L não forem especificadas. Entretanto, mesmo se é seguro fazê-lo, os resultados impressos pelo e2fsck não são válidos se o sistema de arquivos estiver montado.Se o e2fsck perguntar se você deve ou não verificar um sistema de arquivos que está montado, a única resposta correta é '' não ''. realmente sabe o que eles estão fazendo deve considerar responder a esta pergunta de qualquer outra forma. "

    
por 22.06.2009 / 20:20
28

O problema básico é que o verificador do sistema de arquivos (normalmente) 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 não estão coordenando entre si de maneira alguma. O resultado, como outros apontaram, é que a maioria das damas espera que ninguém mais esteja alterando os metadados do sistema de arquivos enquanto eles são executados. 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 que são explicitamente projetados 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 um instantâneo recente do sistema de arquivos (uma réplica copy-on-write, somente leitura, point-in-time). Se encontrar problemas, como inconsistências nos mapas de bits de alocação, ele os corrigirá por meio da chamada do sistema, em vez de gravá-los 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.

    
por 22.06.2009 / 23:39
10

A execução do fsck em uma leitura / gravação montada na partição seria tola, mesmo com o fsck no modo somente leitura. O sistema de arquivos será alterado sob fsck, e os dados na memória que o fsck armazena no sistema de arquivos se tornarão inválidos (e, portanto, o fsck verá inconsistências). Você pode executar o fsck em um sistema de arquivos montado somente leitura no modo somente leitura e obter resultados válidos. Executando o fsck no modo de leitura / gravação em um sistema de arquivos montado somente para leitura, se o fsck fizer alterações no sistema de arquivos durante o curso de sua execução, fará com que o kernel veja as estruturas do sistema de arquivos sendo alteradas inesperadamente. Isso também seria ruim.

    
por 22.06.2009 / 20:19
8

Além do fato de que ele provavelmente mataria sua taxa de transferência de E / S, se o sistema de arquivos estiver sendo modificado enquanto estiver sendo fsck'd, não há como o fsck rastrear as mudanças e reportar inconstâncias.

Alguns sistemas de arquivos, como o XFS, permitem que você execute 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_check recomenda que o sistema de arquivos seja desmontado ou montado somente para leitura antes de executar a verificação.

    
por 22.06.2009 / 20:17
5

Bem, o objetivo do fsck é relatar inconsistências no sistema de arquivos, ou seja, invariantes violados.

No entanto, muitas dessas verificações envolvem mais de uma estrutura de FS. Se alguém estiver modificando o FS (escrevendo dados), essas estruturas podem estar temporariamente fora de sincronia. O fsck veria isso como 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 um problema permanente que precisa ser consertado. Então, isso não pode funcionar (a menos que um FS seja projetado especificamente para permitir a verificação online. Alguns fazem, mas o ext3 não).

    
por 22.06.2009 / 20:34
2

Bem, você pode. fsck -n / dev / sda1 fará exatamente isso, pelo menos no ext3. Eu apenas testei :)

    
por 22.06.2009 / 20:16
-3

Você pode, assim como você pode enfiar a mão em um liquidificador em movimento e possivelmente não se machucar, ou apenas como você pode pular de um prédio alto enquanto aponta para a pequena pilha de almofadas que você colocou na calçada abaixo. / p>

Mas por que você, além de testar sua própria mortalidade? Porque seu chefe certamente irá testá-lo novamente quando descobrir porque o servidor de email não reconhecerá o drive raiz agora.

    
por 23.06.2009 / 00:35