[solved] Linux:: xfs odds!!!

[0db]

FS (dm-10): SB validate failed
SOLUTION VERIFIED - Updated June 29 2019 at 12:55 PM - English
Environment
Red Hat Enterprise Linux 6
xfsprogs
Issue
Unable to mount xfs filesystem, getting below error.
Raw
XFS (dm-10): bad version
XFS (dm-10): SB validate failed
Resolution
Currently it is not possible to mount xfs filesystem on RHEL 6 which is formatted on RHEL 7.
In order to resolve the issue, mount the xfs filesystem on RHEL 7 and take the data backup. Recreate xfs filesystem on RHEL 6 and restore the data from the backup.
Root Cause
The features of XFS V5 are neither tested nor supported in Red Hat Enterprise 6. By default xfs filesystem created on RHEL 6 will have the below features.
Raw
xfs_db -c version /dev/mapper/testvg-testlv
versionnum [0xb4a4+0xa] = V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT
Diagnostic Steps
Monitor dmesg while trying to mount xfs filesystem.
Raw
$ mount /dev/mapper/testvg-testlv /data
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

# dmesg | tail -f
SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
XFS (dm-10): bad version
XFS (dm-10): SB validate failed
Check current xfs version and feature bits for the affected filesystem
Raw
On RHEL 6 system:
# xfs_db -c version /dev/mapper/testvg-testlv
xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided.
cache_node_purge: refcount was 1, not zero (node=0x1308210)
xfs_db: cannot read root inode (117)
cache_node_purge: refcount was 1, not zero (node=0x1308810)
xfs_db: cannot read realtime bitmap inode (117)
xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided.
versionnum [0xb4a5+0x18a] =

On RHEL 7 system:
# xfs_db -c version /dev/mapper/testvg-testlv

This is really a point to know.

Currently it is not possible to mount xfs filesystem on RHEL 6 which is formatted on RHEL 7.
In order to resolve the issue, mount the xfs filesystem on RHEL 7 and take the data backup. Recreate xfs filesystem on RHEL 6 and restore the data from the backup.

which version did make the difference? xfsprogs >= v4.5?

[I wanted a rude username]

which version did make the difference? xfsprogs >= v4.5?

Whichever version it was, note that Red Hat don't support XFS on RHEL 6 unless you pay extra (Scalable File System entitlement). And that regular support will end in November regardless. So best not to invest too much effort into this release with its decade old kernel unless you have some really good reason.

[greenpossum]

Learnt this the hard way.

https://green-possum-today.blogspot.com/2018/04/xfs-partition-created-under-centos-7.html

Users wanted to go back to CentOS 6 because applications were not qualified for CentOS/RHEL 7.

If you don't have a need for CentOS/RHEL 6, go to 7 or even 8.

[0db]

It doesn't care about Red-Hat certifications, except they document the problem. Assuming you are using the same kernel version (both my machines are v4.9) , just talking about the userland, I have just personally verified that if you use a 2020-updated machine to format an XFS partition then a 2011-updated machine cannot check the partition.

I haven't understood it yet, but it seems it's 100% related to xfsprogs and (maybe also) e2fsprogs.

[greenpossum]

There was a version update to the xfs partition format which affects the kernel driver and the userland tools in between 6 and 7, that's all. Nothing to do with e2fsprogs, different filesystem type.

[0db]

There was a version update to the xfs partition format which affects the kernel driver and the userland tools in between 6 and 7, that's all. Nothing to do with e2fsprogs, different filesystem type.

I have experimented it personally, it shows the same errors reported in the Red-Hat's note. In my case, with the same kernel version, two different versions of xfsprogs offer two different behaviors.

Code: [Select]

# xfs_db -c version /dev/sda3
xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided.
cache_node_purge: refcount was 1, not zero (node=0x1308210)
xfs_db: cannot read root inode (117)
cache_node_purge: refcount was 1, not zero (node=0x1308810)
xfs_db: cannot read realtime bitmap inode (117)
xfs_db: WARNING - filesystem uses v1 dirs,limited functionality provided.
versionnum [0xb4a5+0x18a] =

xfs_db is part of xfsprogs

CentOS/RHEL 7 uses a modern version of xfsprogs than the one on CentOS/RHEL 6, exactly like my 2020-updated computer uses a modern version of xfsprogs than the one on my 2015-updated computer.


I still have to understand from which version of xfsprogs there is the problem.

[0db]

Now, the XFS usb-stick made on my workstation has been tried on 4 computers:
(workstation) kernel v5, rootfs 2020: able to mount, able to run xfs_tools
(server) kernel v4.9.16, rootfs 2020: able to mount, able to run xfs_tools
(server) kernel v4.9.16, rootfs 2015: able to mount, unable to run xfs_tools
(server) kernel v4.4.197, rootfs 2011: able to mount, unable to run xfs_tools

[greenpossum]

It's not just the userland progs, the kernel filesystem module also has to be the updated version, as I have already said.

[RoGeorge]

I'm using ZFS for more than a year now.  Always worked perfectly, very easy to administer, and I think it can do more than XFS can.  Maybe you want to try ZFS instead.

So far, to me ZFS was a zero maintenance filesystem, indeed!   

[0db]

tested xfsprogs v3.2.0 -> problem appeared
updated xfsprogs to v3.2.4 -> problem solved
updated xfsprogs to v5 -> still working

Code: [Select]

v2.6.25    2005-02
v2.8.18-1  2007-01
v2.9.7-1   2008-03
v3.1.7     2012-01
v3.1.8     2012-09
v3.1.10    2013-01
v3.1.11    2013-07
v3.2.0     2014-05 <-------------- Xfs v5 early support
v3.2.1     2014-07
v3.2.2     2014-12
v3.2.3     2015-06
v3.2.4     2015-07 <-------------- Xfs v5 full support
v4.2.0     2015-09
v4.3.0     2015-11
v4.5.0     2016-03
v4.7.0     2016-08
v4.8.0     2016-10
v4.9.0     2017-01
v4.10.0    2017-02
v4.11.0    2017-05
v4.12.0    2017-07
v4.13.1    2017-09
v4.14.0    2017-11
v4.15.0    2018-02
v4.15.1    2018-02
v4.16.1    2018-05
v4.17.0    2018-06
v4.18.0    2018-08
v4.19.0    2018-11
v4.20.0    2019-02
v5.0.0     2019-05
v5.1.0     2019-07
v5.2.0     2019-08
v5.2.1     2019-08
v5.3.0     2019-11

Digging deeper
before v3.2.0, there was support for xfs-v4
after v3.2.4 there was support for xfs-v5
between v3.2.0 and v3.2.4 it was stabilization