I have a large, frequently read, ext3 file system mounted read-only on a system that is generally always hard power cycled about 2-3 times per day.

Because the device is usually powered off by cutting the power, fsck runs on boot on that file system, but for this application fast boot times are important (to the second).

I can disable boot time checks on the file system in fstab, but my question is, is it safe to do this? Given that the file system is mounted read-only but is never unmounted properly, is there any risk of accumulating file system corruption over a long period of time if I disable the boot time check?


3 Answers 3


From the mount 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).

If ro,noload should prove to be insufficient, I know of no way to set up a read only device with just an fstab entry; you may need to call blockdev --setro or create a read-only loop device (losetup --read-only) by some other means before your filesystem is mounted.

If you make it truly read-only, it won't even know it was mounted. Thus no mount count updates and no forced fsck and especially no corruption possible, as long as nothing ever writes to the device...

  • Thanks, I didn't actually know about noload; this is exactly the info I was looking for. I can do blockdev in initramfs if necessary.
    – Jason C
    Oct 17, 2013 at 17:16
  • “If you make it fully read-only, it won't even know it was mounted.” There's a caveat: if the filesystem was not cleanly unmounted, then mount -r will replay the journal and thus modify the filesystem. Oct 17, 2013 at 22:10

From the tune2fs 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

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

So you can set both to zero, which should disable automatic fsck's (assuming you actually want to do that, though).

  • Thanks; I may have worded my question poorly. I know how and actually want to disable automatic fscks. My question was does disabling automatic fsck on a frequently uncleanly shut down but read-only mounted file system add a risk of corruption build up.
    – Jason C
    Oct 17, 2013 at 16:30
  • Yes, because disks eventually go bad and fsck will allocate bad sectors to a bad block group so that they don't get used for storing any data.
    – Bratchley
    Oct 17, 2013 at 16:53
  • It's an SD card; bad sectors will not develop (although eventually it will simply fail entirely due to write cycle limitations, which is why we're mounting it read-only).
    – Jason C
    Oct 17, 2013 at 17:14

Leaving my other answer for historical and contextual reasons, but re-reading I am seeing your actual question: Yes, you still want to eventually do an fsck. All disks have a finite life and fsck will allocate bad sectors to a "bad block" inode/list so that no new files will use them.

Being read-only (and doing the noload stuff frotschutz is talking about) helps prevent consistency issues due to service interruption, but you still need to account for your hardware just plain dying off.

  • Thanks. It's an SD card; bad sectors will not develop (although eventually it will simply fail entirely due to write cycle limitations, which is why we're mounting it read-only). Does that change the answer?
    – Jason C
    Oct 17, 2013 at 17:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .