e2fsck -n on mounted ext3 disk always reports errors?

English Install/Boot/Login
1

I’ve noticed that running e2fsck with the -n option on a mounted ext3 filesystem that has been in use will always reports errors in SuSE versions 9.3 onwards. Is this intentional?

If the partition is umounted, fsck’d and then remounted then it reports clean but once a file is changed or created on this disk, it’s then marked unclean. This seems to happen on SuSE 9.3, 10.3 and 11.0 - running e2fsck -n on SuSE 8.2 (or any Red Hat or Slackware version) does not exhibit this behaviour. Has anyone else noticed this?

Andy

2

Hi Andy.

You shouldn’t e2fsck a mounted drive.

E2fsck supports ext2 and also ext3 provided you unmount it. When you unmount ext3 the journal is applied and the files are marked clean. But if you don’t unmount it then e2fsck will see them as not clean.

I can’t speak for SuSE 8.x because I wasn’t around then.

3

The -n option to e2fsck allows you to check a mounted filesystem but not make any changes to it. So it will report any errors found but not make any changes and is apparently safe to use on mounted filesystems.

I think maybe e2fsck has been compiled with different options - or even from different source - in SuSE 9.3 and later (I have access to a SuSE 9.0 system so I could check that too). But e2fsck with the -n option in SuSE 8.2 and other Linux distros report clean filesystems.

I just wondered if it was a feature of SuSE’s e2fsck.

Andy

4

While you can use -n on a mounted filesystem, that is not the main purpose of its existence. It exists so that a suspect non-mounted filesystem can be examined without any danger of changing anything.

Nowhere are you guaranteed that when e2fsck runs on a mounted filesystem it will find everything consistent. As a mounted filesystem is in use, more likely than not it will have inconsistencies because part of its state is in RAM. So it is pointless to check a mounted filesystem.

5

I agree that part of the filesystem state is in memory and that some data will be residing in buffers, etc but why is it that the e2fsck utility does not report any errors when used on, say, Rad Hat or Slackware or indeed, SuSE 8.2?

Just curious, that’s all.

Andy

6

Are you sure looks like a rh mailing list to me…

Nabble - Ext3 - User - e2fsck discrepancies

7

That’s an interesting thread on nabble - thanks for the pointer.

OK, well I’ll not trust e2fsck -n on mounted filesystems any more. I only executed this out of interest as /dev/sdd1 throws up a series of SCSI errors about once a year and brings the server down - this disk contains MySQL databases. I’m replacing the disk and hopefully that will fix the problem permanently.

cheers, Andy

8

You could run smartctl and see if there are any hardware errors logged in SMART.