Por que o FSCK é executado mesmo que você nunca tenha um desligamento impuro?

Question

AFAIK FSCK verifica e repara o sistema de arquivos em caso de um desligamento impuro, como falha de energia (não tenho certeza). Eu tenho um servidor que nunca teve desligamentos impuros, mas ainda assim o FSCK funcionou em algum momento depois de alguns meses. O FSCK é realmente necessário, mesmo se você nunca teve desligamentos impuros?

    

Answer 1

man 8 tune2fs na verdade responde às suas perguntas:

-c max-mount-counts

Adjust the number of mounts after which the filesystem will be checked by e2fsck(8). If max-mount-counts is 0 or -1, the number of times the filesystem is mounted will be disregarded by e2fsck(8) and the kernel.

Staggering the mount-counts at which filesystems are forcibly checked will avoid all filesystems being checked at one time when using journaled filesystems.

You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point.

See also the -i option for time-dependent checking.

-i interval-between-checks[d|m|w]

Adjust the maximal time between two filesystem checks. No suffix or d will interpret the number interval-between-checks as days, m as months, and w as weeks. A value of zero will disable the time-dependent checking.

It is strongly recommended that either -c (mount-count-dependent) or -i (time-dependent) checking be enabled to force periodic full e2fsck(8) checking of the filesystem. Failure to do so may lead to filesystem corruption (due to bad disks, cables, memory, or kernel bugs) going unnoticed, ultimately resulting in data loss or corruption.

Quanto a encontrar a frequência de verificações (após os limites max-mount-counts ou intervalo entre verificações ) definidas em seu próprio ext2 / ext3 / ext4 sistema de arquivos, você pode executar este comando:

sudo dumpe2fs /dev/YOURDEV | grep -Ei '(mount count|interval|check)'

Substitua /dev/YOURDEV pela partição que você deseja examinar.

Exemplo de saída:

deltik@node51 [~]$ sudo dumpe2fs /dev/nvme0n1p3 | grep -Ei '(mount count|interval|check)'
dumpe2fs 1.42.13 (17-May-2015)
Mount count:              1
Maximum mount count:      -1
Last checked:             Tue Mar 15 13:30:00 2018
Check interval:           0 (<none>)

    

Answer 2

Is FSCK really needed even if you never had unclean shutdowns?

Isso depende. Você pode garantir com 100% de certeza que você nunca terá nenhum qualquer corrupção de dados no sistema de armazenamento abaixo do sistema de arquivos?

Como regra geral, uma verificação de sistema de arquivos é funcionalmente obrigatória após um desligamento inadequado em determinados sistemas de arquivos (mais antigos, mais especificamente ext4), mas um desligamento não limpo não é a única situação que pode fazer com que as estruturas de dados internas dos sistemas de arquivos tornar-se corrompido. Falhas de dispositivos não catastróficas (setores defeituosos, firmware defeituoso, etc) podem causar exatamente o mesmo tipo de corrupção, por isso geralmente é uma boa idéia verificar de vez em quando, mesmo que o sistema não trave ou perca energia.

Isso é particularmente importante no ext4 porque:

• Ao usar o registro no diário (se você não sabe se está ou não está usando o registro no diário, provavelmente está), o sistema de arquivos pode nunca ser verificado de outra forma, porque um sistema de arquivos com diário é autoconsistente mesmo depois de uma impureza desligamento.
• O comportamento padrão ao encontrar erros nos metadados do sistema de arquivos em tempo de execução é simplesmente registrar o problema e continuar como se nada tivesse acontecido. Isso significa que, comparado a outros sistemas de arquivos (por exemplo, XFS, BTRFS ou ZFS), é muito menos provável que você perceba se há um problema com o sistema de arquivos até que seja tarde demais para corrigi-lo.