Partitions mounted read-only do not increment mount count.

subi211 · 12-05-2013, 06:31 AM

I have a minimum Ubuntu 12.04 install running on a homebrew arcade machine. The disk is an SSD split into three partitions, OS, Game and Log, all ext4. To avoid corruption issues, the OS and Game partitions are mounted as read-only by fstab, while Log is mounted read-write as normal.

One evening, when turning the machine on, Log refused to mount with a can't-start-journalling error. fsck fixed it in a jiffy, but I decided to start running fsck on each boot to automate the process should such an error ever occur again.

I dutifully performed tune2fs -c 1 on each partition and left it at that. However, over the next few days I noticed that the fsck didn't seem to be talking up much (if any) time. Given that there is well over a GB of data on the OS partition alone I would have expected it to at least be visible.

I checked when the last check was done via dumpe2fs -h, and found that checks were NOT being performed on the two read-only partitions. This seemed to be caused by the mount count not incrementing - it was 0 for OS and Game, but 1 for Log.

I changed OS and Log to mount read-write and the mount count was incremented and the check was duly performed on each boot. Making them read-only again stopped it.

Given that this is information updated by (presumably) the mount command, I would have expected the mount count to be incremented no matter what the partition is mounted as. Is there any way I can force the mount count to be incremented no matter what state the partition is mounted as?

rknichols · 12-05-2013, 01:43 PM

Updating the mount count would require writing to the super block, and that is something the mount command is never going to do for a read-only mount. You could use the tune2fs command's "-C" (upper case) option to adjust the current mount count at any time:

Code:

Dev=/dev/sda2
Count=$(tune2fs -l $Dev | sed -ne 's/^Mount count: *//p')
tune2fs -C $((Count+1)) $Dev

An alternative would be to momentarily remount the file system read-write:

Code:

mount -o remount,rw /whatever
mount -o remount,ro /whatever

But, that is something you probably don't want to do routinely to your read-only partitions.

Or, you could just set the time interval between checks to some non-zero value and let that trigger the check.

syg00 · 12-06-2013, 04:48 AM

Quote:

Originally Posted by subi211

Is there any way I can force the mount count to be incremented no matter what state the partition is mounted as?

I wouldn't think so.
Not with (current) ext4 anyway. Used to be "read only" was effectively ignored, and any outstanding journal entr{y,ies} was/were always replayed on mount - even a "read only" mount. Messed with forensic/recovery situations something terrible.

Ted changed this a while back on ext4 so read only means just that.

Maybe convert to ext3 if you really feel the need - but what benefit is fsck on a filesystem that's never updated ?.

subi211 · 12-06-2013, 11:09 AM

Quote:

Originally Posted by syg00

Maybe convert to ext3 if you really feel the need - but what benefit is fsck on a filesystem that's never updated ?.

Almost certainly none, you're quite correct. I've been trying to thing of anything that could affect a read-only filesystem and I couldn't come up with anything (corruption due to power failure being my major concern). But I thought better safe than sorry.

Also, I was curious. I would have thought that superblock information was required to be accurately maintained, even on read-only, so I was quite surprised when it wasn't. However, that being said...

Quote:

Originally Posted by rknichols

Or, you could just set the time interval between checks to some non-zero value and let that trigger the check.

Yes, that does work. Even manages to write the last check and last write times to the superblock (although the last mount time remains un-updated). So something still writes to it while it's read-only anyway.

rknichols · 12-06-2013, 02:01 PM

Quote:

Originally Posted by subi211

So something still writes to it while it's read-only anyway.

At the time fsck is run, the file system isn't mounted at all.

jpollard · 12-06-2013, 03:13 PM

Quote:

Originally Posted by subi211

Almost certainly none, you're quite correct. I've been trying to thing of anything that could affect a read-only filesystem and I couldn't come up with anything (corruption due to power failure being my major concern). But I thought better safe than sorry.

Also, I was curious. I would have thought that superblock information was required to be accurately maintained, even on read-only, so I was quite surprised when it wasn't. However, that being said...

Yes, that does work. Even manages to write the last check and last write times to the superblock (although the last mount time remains un-updated). So something still writes to it while it's read-only anyway.

You are specifically directing fsck to update the filesystem...

And as other pointed out, fsck only works when the filesystem is NOT mounted. IF all you are doing is checking for problems, but don't want anything updated, use the -N option.