9 thoughts on - Xfs Fsck Error Metadata Corruption

• sounds to me like there are hardware problems on this system, that the disks are corrupting data. bad ram can do this if there’s no ECC to detect the hardware corruption. so can buggy/broken hardware RAID
  controllers.

  —
  john, recycling bits in santa cruz

• Hi,

  Can CentOS be used with ext3 or ext4 partitioning?

  Steve

• Better to speak of ext3 and ext4 as filesystems, rather than partition types. The partition type is 83 in both cases, which doesn’t distinguish them.

  All current versions of CentOS support ext3, both in the installer and after installation. ext4 was only added to the installer in the most recent version, CentOS 7.

• versions up to and including 6 used ext by default. xfs is the default in CentOS 7, and has worked perfectly for me.

• Yes (as someone else said, they’re filesystem types, not partition types), but if there is a hardware issue, as John noted, ext3 or ext4
  won’t solve the problem. xfs is usually fairly solid, so it is very unlikely that the filesystem type is a problem.

  You should probably run memtest86+ for at least 24 hours to see if that’s an issue. If that doesn’t find anything, you should probably investigate your storage system (as John also mentioned, hard drives and drive controller would both be suspects).

  –keith

• For future reference -L is a big hammer. If you use it without explicitly attempting a read-write mount (which a read only mount at boot time will not do because it’s an ro mount by default), it will almost invariably corrupt the file system worse. My 20/20 hindsight advise is that if a normal mount fails, and xfs_repair fails, then follow this:
  http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
  And report it to the XFS list straight away. There’s a much lower chance someone on this list will know what to do, than the XFS list. And BTW neither list can answer your question without a complete dmesg
  (not just the trace, it’s really annoying to get just the “cut here”
  stuff with drive related problems because almost certainly the real problem occurred before XFS got P.O.d.)

  Sorry, but you’ve given us absolutely no information at all. There’s more than 8001 possibilities. So the least you can do is extract the rdsosreport.txt if you’re dropped to a shell. Or boot from install media, with the rescue boot parameter option, and try mounting the volume, and if that fails, also xfs_repair and give that result. And then collect dmesg which will have mount failure info for sure, and maybe it will also have extra messages from xfs_repair.

  No the installer uses a combination of wipefs, and will also zero some important sections that sometimes cause problems down the road if they aren’t zero’d.

  —
  Chris Murphy

• …for the root filesystem, anyway. For nonroot filesystems it should use whatever flags are set in fstab. (Granted many boxes likely have /
  as the only on-disk fs.)

  –keith

• Even the root ro to rw remount swicheroo is antiquated. Not ext3/4, XFS, nor Btrfs want you to run an fsck on an ro mounted volume. Both e2fsck and xfs_repair use strong wording saying not to do it, to the point I think it’s crusty weirdness to keep the code allowing things like “dangerous” mode repair. The btrfs check tool on the other hand will neither check nor repair a mounted volume – it’s actually a nearly last resort there. Usually normal mount fixes things, and if not the first option is to use -o recovery mount option.

• Could be totally irrelevant but once I had serious fs corruption problems after hibernation on a Fedora laptop with Intel graphics.