0

In RHEL 7.9 I formatted my large /data volume with XFS 4.5. In RHEL 8.8 XFS is version 5.0.

XFS v5 in RHEL 8 can mount an XFS v4 file system created by RHEL 7.9, however RHEL 7.9 cannot mount an XFS v5 file system created by RHEL 8.8.

  • Have to migrate from RHEL 7.9 to RHEL 8.8; in doing so do I leave my /data as is created by RHEL 7.9 with XFS 4.5? Or is it worthwhile to move terabytes of data and reformat my data storage under RHEL 8.8 with XFS v5?
  • If I leave my data formatted as XFS 4.5, going forward with RHEL 8.8 (no likelihood of using RHEL 9 anytime within next 4 years) what could be some potential problems? I've had zero problems using XFS thus far.
Improve this question
1
  • I'll assume that running your RHEL 7.8 with a less hm paleontologically interesting kernel is not an option, right, because that stable kernel is probably the reason you're on RHEL 7.9.
    – Marcus Müller
    Commented Jul 31, 2023 at 16:52

2 Answers 2

Reset to default
1

I think you can do this by disabling one of the features that Rhel8 provides. Format the space on Rhel8 with mkfs.xfs -m reflink=0 /dev/sdN The -m reflink=0 will allow mount on both systems but the relink feature on Rhel8 will not be usable. Also see https://access.redhat.com/solutions/4582401 (will need Redhat login) for more details.

Improve this answer
0
1

The Linux kernel configuration help says this about XFS version 4:

Option CONFIG_XFS_SUPPORT_V4, "Support deprecated V4 (crc=0) format"

The V4 filesystem format lacks certain features that are supported by the V5 format, such as metadata checksumming, strengthened metadata verification, and the ability to store timestamps past the year 2038. Because of this, the V4 format is deprecated. All users should upgrade by backing up their files, reformatting, and restoring from the backup.

If this large amount of data is expected to be long-lived, the year 2038 is not so very far away any more. However it is likely that you'll need to upgrade your hardware at least once or twice before that; you should keep in mind that the filesystem version migration needs to be done at some point before that year. It might be most convenient to do the filesystem version migration together with a hardware upgrade, if you plan accordingly.

As time goes on, the distributions might even remove the support of the XFS version 4 well in advance of the cut-off year in their new major releases, so eventually a big OS upgrade might force you to do the migration anyway.

As far as I know, XFS version 5 has turned out to be very stable with no particular issues.

Just be aware of this in your long-term planning for now.

Newer kernels have already started to warn about the timestamp limit of the XFS filesystem when appropriate. With them, you'll see a message like this from the kernel in dmesg:

xfs filesystem being mounted at <path> supports timestamps until 2038

Depending on the version of tools used to create the filesystem, even XFS V5 filesystems might cause this warning. But on XFS version 5, that can be fixed without a backup/restore cycle by running xfs_admin -O bigtime=1 on the filesystem while it's unmounted and error-free. I've recently done that on a Debian system after an upgrade from Debian 11 to 12 - the operation was quick and trouble-free.

Improve this answer

You must log in to answer this question.

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