'e2fsck -n' + como saber se precisa executar o e2fsck para consertar blocos corrompidos?

Question

Queremos verificar o sistema de arquivos nos discos como /deb/sdc ... /dev/sdg em cada máquina Red Hat Linux.

O objetivo é descobrir quais são os discos que exigem e2fsck (como e2fsck -y /dev/sdb etc.)

De acordo com a página man

-n
Open the filesystem read-only, and assume an answer of 'no' to all questions. Allows e2fsck to be used non-interactively. This option may not be specified at the same time as the -p or -y options.

Quando executamos o comando (exemplo)

 e2fsck -n /dev/sdXX

nós recebemos

e2fsck 1.42.9 (28-Dec-2013)
Warning!  /dev/sdc is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sdc: clean, 94/1310720 files, 156685/5242880 blocks

Então, o que precisamos capturar de e2fsck -n output, que exige que executemos e2fsck (sem -n )?

processo e2fsck

init 1
umount /dev/sdXX
e2fsck -y /dev/sdXX  # (or e2fsck -C /dev/sdXX for full details) 
init 3

    

Answer 1

Você usa e2fsck , então eu suponho que estamos falando de ext? filesystem. O comando

tune2fs -l /dev/sdXX

informará o estado aparente do sistema de arquivos (que pode ser montado, é seguro). Você terá (entre outras coisas) ou

Filesystem state:   clean

ou algo diferente de clean . Como grep retorna false se a correspondência não for encontrada, sua tentativa básica pode ser assim:

tune2fs -l /dev/sdXX | grep "^Filesystem state:[ ]*clean$" || { commands; to; fix; the; filesystem; }

Os itens acima funcionarão somente se o sistema de arquivos tiver detectado seu estado impuro de antemão. Às vezes, você quer verificar problemas de qualquer maneira (é por isso que o comportamento desejado é fsck a cada Nth mount ou quando tal e tal número de dias tiver passado). Se eu entendi bem, você está tentando saber se deve e2fsck -y /dev/sdXX , analisando a saída de e2fsck -n /dev/sdXX .

Eu digo não analise a saída. Verifique o status de saída. Veja man 8 e2fsck para aprender:

The exit code returned by e2fsck is the sum of the following conditions:
0 - No errors
1 - File system errors corrected
2 - File system errors corrected, system should be rebooted
4 - File system errors left uncorrected
8 - Operational error
16 - Usage or syntax error
32 - e2fsck canceled by user request
128 - Shared library error

Nota e2fsck -n /dev/sdXX não fará nada de útil (e retornará "nenhum erro") se o sistema de arquivos parecer claro; então essa é outra maneira de detectar o estado atual aparente , como fizemos com tune2fs . Para verificar de qualquer maneira, você precisa da opção -f . Em seguida, você deseja saber se o status de saída inclui 4 . Em bash isso pode ser feito com:

e2fsck -nf /dev/sdXX  # this is safe even if the filesystem is mounted
status=$?
[ $(( $status & 4 )) -eq 4 ] && { commands; to; fix; the; filesystem; }

Explicação rápida:

• $? é o status de saída do último comando ( e2fsck neste caso). Eu salvá-lo em uma variável separada para que eu possa fazer vários testes com ele. Não é necessário neste exemplo simples, onde há apenas um teste, mas uma boa prática em geral. O motivo subjacente é: após essas linhas, $status ainda contém o status de saída de e2fsck e pode ser reutilizado, enquanto (o novo) $? não tem nada a ver com e2fsck .
• $(( ... )) faz aritmética de shell
• em que & é bit a bit AND,
• então [ ... -eq 4 ] é de fato o comando test para verificar se o resultado é 4 .
• Se o teste for bem-sucedido, o bloco { ... } será executado.

Pode haver erros não dentro do próprio sistema de arquivos, mas em um nível mais profundo, no dispositivo. Eu acho que isso está fora do escopo desta questão, mas apenas para apontar na direção certa no caso de você precisar, esses são comandos úteis (observe sdX , não sdXX ):

• smartctl -t long /dev/sdX
• badblocks -n -b 512 /dev/sdX

Leia as páginas do manual antes de usá-las.

    

Answer 2

Primeiro, verifique se é o sistema de arquivos de registro no diário.

"Um sistema de arquivos journaling é um sistema de arquivos que controla as alterações ainda não confirmadas na parte principal do sistema de arquivos, registrando as intenções de tais mudanças em uma estrutura de dados conhecida como" journal ", que geralmente é um log circular. No caso de um travamento do sistema ou falha de energia, esses sistemas de arquivos podem ser reativados on-line mais rapidamente, com menor probabilidade de serem corrompidos. "

Então você pode experimentar o Gparted para verificar a consistência e ver o que a ferramenta pode fazer por você.