e2fsprogs-1.47.0-1.fc39 With ext4 fs created with 'orphan_file' feature on by default, readonly e2fsck check on a mounted filesystem complains about clearing the orphan file, failing the whole check procedure: # e2fsck -f -n /dev/sdb e2fsck 1.47.0 (5-Feb-2023) Warning! /dev/sdb is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Feature orphan_present is set but orphan file is clean. Clear? no /dev/sdb: ********** WARNING: Filesystem still has errors ********** /dev/sdb: 12/38456 files (0.0% non-contiguous), 15354/153600 blocks # echo $? 4 # umount /dev/sdb # e2fsck -f -n /dev/sdb e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sdb: 12/38456 files (0.0% non-contiguous), 15354/153600 blocks # echo $? 0 # Everything is fine when the filesystem is not mounted, no clearing orphans reported or performed. This is a freshly created filesystem with no writes or files on it. This e2fsck usage has been used for years as a complimentary check from libblockdev and UDisks to detect any issues, on a mounted filesystem. When user decides to repair a filesystem, it will do properly in a separate step. My only complaint is that the request to clear the orphan file looks bogus on a first sight and with the previous checks being successful, this would still fail the whole check operation. A difference from previous e2fsprogs releases. Reproducible: Always
From the e2fsck man page: "it is not safe to run e2fsck on mounted file systems ... The only exception is if the -n option is specified ... However, even if it is safe to do so, the results printed by e2fsck are not valid if the file system is mounted." It really is not valid to check a mounted filesystem, ever. There is no guarantee of consistency while the filesystem is live. It may be "safe" to do so with -n, but as mentioned above, the results are not valid. Building this into some other process should be considered an error, even if it has been doing so for years. Where is this code in libblockdev and UDisks that invoke the check?
Okay, thanks for such authoritative answer! At the end I found existing were extra checks for a mounted filesystem in UDisks, it was just the libblockdev side that was unrestricted and carried test cases over a mounted filesystem. I've added clarifications to docs and removed the libblockdev test: https://github.com/storaged-project/libblockdev/pull/907 https://github.com/storaged-project/udisks/pull/1130 This was all about the traditional fsck. For an online consistency check I think we should use scrubbing-like functionality - filed an RFE for UDisks: https://github.com/storaged-project/udisks/issues/1131