[rhelv6-list] fsck -n always showing errors

[francis picabia]

The file systems are typically ext4.  Running current patches on Redhat 6.9.

This isn't something we routinely look at, but after
a couple of VMware systems showing scsi errors, I noticed almost
every Redhat 6 system will show some disk errors from
something like fsck -n / or same on /var

# fsck -n /
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
Warning!  /dev/sda1 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem
check.
/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 22413413 has zero dtime.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -46708735 -(46712832--46712840) +79201706
+79201715 -79201836 -79202321 -(79234801--79234855) +(79234914--79234968)
Fix? no

Free blocks count wrong (42767651, counted=42765254).
Fix? no

Inode bitmap differences:  -22413413
Fix? no

Free inodes count wrong (25523840, counted=25523326).
Fix? no


/dev/sda1: ********** WARNING: Filesystem still has errors **********

/dev/sda1: 526720/26050560 files (0.2% non-contiguous), 61424349/104192000
blocks


The SAN backend for these VMs, nor the host boxes, have no alerts or
warnings.

With one development box I did touch /forcefsck and rebooted.
Retested fsck and still issues.  Repeated this cycle 3 times
and no improvement.

We have seen errors in the file system flagged like this on
physical systems and VMs.  They are not impacting
performance or booting, but given that two showed scsi
errors, I would think there is some possibility of data corruption.

This is too widespread to be any particular hardware system at fault.

I can't tell if there are bugs in ext4 or fsck is giving false positives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20171220/4c9c5ed8/attachment.htm>