É seguro desativar o fsck de inicialização no sistema de arquivos ext3 somente leitura?

Question

Eu tenho um sistema de arquivos ext3 grande, freqüentemente lido, montado somente para leitura em um sistema que geralmente é sempre ligado por ciclo de energia cerca de 2-3 vezes por dia.

Como o dispositivo geralmente é desligado cortando a energia, o fsck é executado na inicialização desse sistema de arquivos, mas, para esse aplicativo, os tempos de inicialização rápidos são importantes (para o segundo).

Eu posso desabilitar as verificações de tempo de inicialização no sistema de arquivos no fstab, mas minha pergunta é, é seguro fazer isso? Dado que o sistema de arquivos é montado como somente leitura, mas nunca é desmontado corretamente, existe qualquer risco de acumular corrupção do sistema de arquivos por um longo período se eu desabilitar a verificação do tempo de inicialização?

    

Answer 1

Na% man_de% manpage,

   -r, --read-only
          Mount the filesystem read-only. A synonym is -o ro.

          Note  that,  depending  on the filesystem type, state and kernel
          behavior, the system may still write to the device. For example,
          Ext3 or ext4 will replay its journal if the filesystem is dirty.
          To prevent this kind of write access, you may want to mount ext3
          or  ext4  filesystem  with  "ro,noload" mount options or set the
          block device to read-only mode, see command blockdev(8).

Se mount for insuficiente, não sei como configurar um dispositivo somente leitura com apenas uma entrada fstab; talvez seja necessário chamar ro,noload ou criar um dispositivo de loop somente leitura ( blockdev --setro ) por algum outro meio antes que seu sistema de arquivos seja montado.

Se você o tornar verdadeiramente somente leitura, ele nem saberá que foi montado. Portanto, nenhuma atualização de contagem de montagem e nenhum fsck forçado e, principalmente, nenhuma corrupção possível, desde que nada nunca seja gravado no dispositivo ...

    

Answer 2

Na% man_de% manpage:

   -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 jour-
          naling 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.

e:

   -i  interval-between-checks[d|m|w]
          Adjust the maximal time between two filesystem checks.  No postfix or d result in days, m in months, and w in 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 to go unnoticed until they cause data loss or corruption.

Assim, você pode definir ambos como zero, o que deve desativar o tune2fs automático (supondo que você realmente queira fazer isso, no entanto).

    

Answer 3

Deixando minha outra resposta por motivos históricos e contextuais, mas relendo estou vendo sua pergunta: Sim, você ainda deseja eventualmente fazer um fsck . Todos os discos têm uma vida finita e fsck alocará setores inválidos para um "bloco ruim" inode / list, de modo que nenhum arquivo novo os use.

Ser somente leitura (e fazer o noload stuff frotschutz está falando) ajuda a evitar problemas de consistência devido à interrupção do serviço, mas você ainda precisa levar em conta o seu hardware simplesmente apagando.