O que há com a mensagem de erro "estrutura precisa limpar"
O erro "estrutura precisa de limpeza" é o erro que os sistemas de arquivos (em particular, ext4 e xfs) retornam quando detectaram um problema de corrupção do sistema de arquivos. Infelizmente, a única coisa segura a fazer para reparar a corrupção é desmontar o disco e executar e2fsck no sistema de arquivos. (Tecnicamente, você não precisará da opção -f porque o sistema de arquivos já detectou problemas e marcou o sistema de arquivos como estando com problemas. Portanto, quando você executar e2fsck , ele fará uma varredura completa para corrigir esses problemas. e você não precisa da opção -f para forçar um cheque.)
Relatórios de corrupção do sistema de arquivos
Você também deve conseguir ver os relatórios de corrupção do sistema de arquivos observando os logs do kernel. (por exemplo, executando dmesg ou observando /var/log/kern.log ou onde quer que seu syslog ou journald tenha sido configurado para registrar as mensagens do kernel. Você deverá ver as mensagens que começam EXT4-fs error (device sdXX) . Por exemplo:
EXT4-fs error (device sda3): ext4_lookup:1602: inode #37005: comm docker: deleted inode referenced: 31872136
Você também pode ver indicações de erros observando dumpe2fs -h no sistema de arquivos. Campos de interesse:
FS Error count: 25
Isso significa que o kernel encontrou inconsistências no sistema de arquivos 25 vezes.
First error time: Thu Jan 1 12:19:59 2015
First error function: ext4_ext_find_extent
First error line #: 400
First error inode #: 95223833
First error block #: 0
O primeiro erro foi encontrado em 1º de janeiro de 2015, no horário especificado. A função de erro e a linha # permitem identificar exatamente qual parte do código do kernel encontrou o problema. O inode # informa qual inode estava envolvido com a inconsistência do sistema de arquivos.
Last error time: Wed Feb 4 11:57:05 2015
Last error function: ext4_ext_find_extent
Last error line #: 400
Last error inode #: 95223833
Last error block #: 0
Isso informa o tempo mais recente em que o kernel encontrou uma inconsistência no sistema de arquivos. Os grandes deltas entre os dois tempos significam que alguém não está examinando suas mensagens do kernel. Isso porque a cada 24 horas, o ext4 registrará em mensagens de aviso que existe um sistema de arquivos com corrupções, e essas mensagens do kernel ficarão assim:
EXT4-fs (dm-0): error count since last fsck: 12
EXT4-fs (dm-0): initial error at time 1441536566: ext4_dirty_inode:4655
EXT4-fs (dm-0): last error at time 1441537273: ext4_remount:4550
Nota: o tempo é que as mensagens do kernel são número de segundos desde 1 de janeiro de 1970, meia-noite, UTC. Você pode converter isso para um horário mais legível usando o comando date, por exemplo:
% date -d @1441536566
Sun Sep 6 06:49:26 EDT 2015
O que fazer quando você perceber que seu sistema de arquivos está corrompido
Você realmente não deseja executar inconsistências no sistema de arquivos, pois isso pode levar a mais perda de dados. É realmente uma boa idéia entrar nesses relatórios, agendar o tempo de inatividade, se necessário, e corrigi-los o mais rápido possível.
Por que e2fsck reclamou que o dispositivo estava em uso depois de desmontá-lo?
Por fim, responda à sua pergunta: "Corri fsck após a desmontagem e recebi o seguinte erro: /dev/sdb1 is in use. Alguma idéia?" Provavelmente, isso ocorre porque você tem um ou mais processos em um namespace de montagem alternativo, e esses processos ainda têm /dev/sdb1 montado no espaço de nome de montagem. Você pode querer tentar:
grep /dev/sdb1 /proc/*/mounts
Se você encontrar processos em execução em um namespace de montagem alternativo, a coisa mais simples a fazer é eliminar e reiniciar esses processos. (Eles são provavelmente processos daemon.) Quando o último processo usando um namespace de montagem é encerrado, o espaço de nome da montagem desaparece. E quando não houver mais namespaces de montagem que tenham /dev/sdb1 montado, ele realmente será desmontado de verdade.
A maneira de pensar sobre isso é que umount age como unlink . Se você tiver um arquivo com vários hardlinks, o espaço será liberado apenas quando o último link físico for excluído. Se você tiver vários namespaces ativos, cada namespace funcionará efetivamente como um "link físico" para a montagem em questão. Portanto, simplesmente desmontar o sistema de arquivos no namespace de montagem padrão não ajudará se algum processo bifurcou o namespace de montagem padrão e está executando ele mesmo e possivelmente alguns processos filhos nessa cópia copy-on-write de seu namespace de montagem pai.