Roland Bock wrote:
> yesterday I ran e2fsck -n on a mounted file system and got:
> /dev/sdb1 contains a file system with errors, check forced.
> According to Ted, the lines that followed were not to be trusted due to
> the fact that the file system was mounted. But this error statement
> suggests to run a check with the fs unmounted.
> Today, we scheduled a downtime and ran the check. It came of completely
> ~: e2fsck -fy /dev/sdb1
> e2fsck 1.40.8 (13-Mar-2008)
> 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/sdb1: 32028520/536870912 files (0.5% non-contiguous),
> 802465197/2147460933 blocks
> Does this mean that read-only checks are generally not trustworthy, even
> the statement that the filesystem has errors? Or something like
> Read-only reports clean: fine
> Read-only reports error: not necessarily really an error
I think that's possible. When e2fsck starts off, main() does:
if some sanity tests fail
if EXT2_ERROR_FS || !ext2fs_test_valid()
" contains a file system with errors"
check_if_skip is what issues the "contains a file system with errors"
message, and it may do so if the filesystem is marked with errors, OR if
a call to ext2fs_test_valid() fails.
Prior to this, check_super_block() may call ext2fs_unmark_valid() for a
variety of reasons, some of which could, I think, be caused by the
filesystem being live and not necessarily consistent when viewed by e2fsck.
So I think that the message is a bit misleading; "filesystem with
errors" sounds to me like EXT2_ERROR_FS, which should always issue some
sort of message to the syslog when set - but, you may also get the
"filesystem with errors" message due to some inconsistencies that may be
wholly due to the filesystem being mounted and in flux as fsck tries to
Ext3-users mailing list