I have a system, where I generate an XFS filesystem image on one system, and then use this image in another system. Currently both use CentOS7 (7.9 and 7.8 respectively). This works reliably.

However, in order to get rid of CentOS once and for all, I am gradually moving to RHEL (and/or Alma Linux).

In a transition period, the 'generator' system will move to RHEL, but I can't change the 'consumer' yet.


If I naïvely try to mount the XFS file system (generated by RHEL9) on the CentOS7 system, I get an error message:

root@localhost updateFs]# mount -o loop ./fs.img /tmp/fs2/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
[root@localhost updateFs]# dmesg -H | tail -4
[May 5 14:25] XFS (loop0): Superblock has unknown read-only compatible features (0x4) enabled.
[  +0.010671] XFS (loop0): Attempted to mount read-only compatible filesystem read-write.
[  +0.000006] XFS (loop0): Filesystem can only be safely mounted read only.
[  +0.000580] XFS (loop0): SB validate failed with error -22.

If I try to mount it read-only, it looks OK. But I need to be able to write to it.

Is there something I can do on either side, to 'downgrade' the filesystem to a more compatible version?


System distrib kernel xfsprogs
Generator RHEL9.1 5.14.0-162.2.1-el9 5.14.2-1.el9.x86_64
Consumer CentOS7.8 3.10.0-1127.el7 4.5.0-20.el7.x86_64

1 Answer 1


It seems that is the relink feature flag, and it would make sense that such a file system could only be mounted read only on a kernel predating this (IMHO very useful) file system feature.

There's no tool to disable that feature after it's been used at file system creation time. You will have to make a new file system and copy over the contents of the old.

mkfs.xfs -m reflink=0 -f yourfilesystemimage
  • Thank you - yes, that seems to be the best (only?) option. Quick follow-up question: Is there a better way to copy the contents of a filesystem (including hard-links etc.) than mount -o loop oldfs.img oldfs && mount -o loop newfs.img newfs && (cd oldfs; tar c) | (cd newfs ; tar x)
    – Popup
    Commented May 8, 2023 at 7:36
  • 1
    I think that's proper, it preserves hardlinks. Because I tend to forget which options are default in GNU tar, --xattrs --selinux --acls is what I typically add to any tar invocation. You can probably achieve the same as tar c | tar x by doing xfsdump -J - oldfs.img | xfsrestore -J - newfs/, but I've never tried that (and it shouldn't be significantly faster than tar|tar) Commented May 8, 2023 at 7:57
  • Reading up a bit more on reflink - this does indeed seem like a very useful feature. Why hasn't it made it into e.g. ext4? I see that patches have been proposed for almost a decade!
    – Popup
    Commented May 11, 2023 at 11:47
  • 1
    @Popup changing file systems is actually pretty complicated and extremely testing-intense. Don't ask the XFS community how long proposals for subvolumes and snapshots have been around! Commented May 11, 2023 at 12:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .