Minha partição raiz é formatada como sistema de arquivos ext4.
Percebo que, sempre que a minha máquina falha e tenho que fazer uma reinicialização, quando a inicialização é feita novamente e o sistema de arquivos raiz é verificado, essa etapa leva um pouco mais de um a dois segundos do que quando a inicialização é limpa. no sistema, mas é relatado como "limpo" (e nada como /dev/<rootpartition> was not cleanly unmounted, check forced ). O sistema de arquivos está 92% cheio (352 GiB).
Minha pergunta: Gostaria de saber se este é o comportamento normal e seguro do ext4 ou algum bug nos scripts de inicialização. Eu sei que o ext4 tem um fsck muito mais rápido do que o ext3, mas estou preocupado com o fato de ele ser reportado como "limpo" após uma falha no sistema.
Quando executo e2fsck -f manualmente nessa partição, a verificação dura comparável a um sistema de arquivos ext2 / ext3. Então, eu estou preocupado e desde então eu escolhi o meu sistema de arquivos para ser verificado em cada inicialização ( tune2fs -c 1 ), o que resulta em uma verificação completa, levando em conta e2fsck -f a cada inicialização.
Edite, apenas para esclarecer: Após uma reinicialização não limpa, normalmente, em / var, que é reiserfs, o fsck reproduz entradas de diário; em / boot, que é ext2, o fsck é executado, exibe a barra de progresso e relata "limpo" após a execução. Apenas no sistema de arquivos raiz não há "verificação forçada" e não aparece nenhum progresso fsck, que aparecem para os outros sistemas de arquivos, mesmo que estejam limpos. Essa é a diferença preocupante!
O fsck já ocorre dentro do initrd / initramfs (após um encerramento não limpo leva vários segundos a mais com muita atividade de disco neste estágio, onde o diário parece ser repetido) e, assim, quando o normal , mais detalhadas, as verificações do sistema de arquivos estão sendo executadas a partir do sistema principal, já está limpo.
ext4 é um sistema de arquivos de registro no diário, e um dos principais objetivos do registro no diário é sobreviver a paradas sujas sem danos e, portanto, não exigir um fsck longo.
Em suma, um sistema de arquivos journaling como ext3 / 4 escreve metadados (pelo menos) muda duas vezes . Primeiro, escreve-os no "diário". Então, uma vez no disco, ele grava nos metadados reais do sistema de arquivos. (Escrever para o periódico é muito mais rápido, já que o periódico é seqüencial e não requer um monte de buscas. Pelo menos em discos magnéticos - buscar penalidade é bastante reduzida em SSDs.)
Os vários segundos extras são provavelmente a repetição da revista: basicamente, se o sistema de arquivos não for montado corretamente, a próxima montagem ou fsck lerá o diário e aplicará as alterações que ainda não estão no sistema de arquivos principal. / p>
Então, em resumo, parece que está se comportando como esperado.
O fsck geralmente é executado na inicialização quando o sistema de arquivos não está desmontado corretamente (normalmente quando você precisa reinicializar). O fsck verificará seu sistema de arquivos antes de montá-lo e informará um erro se detectar que algo está errado (inconsistências, falha ao reproduzir o diário, inodes órfãos ...) ou reportará "limpo" se não detectar nenhum erro. Então, no seu caso, você tem sorte e seu sistema de arquivos está ok. Existe um post muito interessante sobre o fsck se você quiser mais algumas informações de como ele funciona internamente: link