Otdfbt

have a XFS partition that I find to act very strangely. It mounts fine under a system but won't mount under others --of which my main system. As I'm new at XFS, I'd love to hear from users more experienced than me before I just forget about XFS.

• Hardware is fine: S.M.A.R.T. shows the three months old 1TB 2.5" Momentus is good; all attributes are like WORST=VALUE. HDD stands in an Inateck external aluminium rack that's USB connected to either of my laptops.


• Partition layout is a dead simple MBR with four primary partitions, the XFS one is where I store all of media stuff (library).
  I created the partitions three months ago under Arch i686 (kernel 3.19-ck) with parted. Had no issues whatsoever accessing it under that system. But under Fedora 16 i686 with an older kernel where it wouldn't mount, even after running xfs_repair.


• Also, I have no issues mounting the other (ext4/swap) partitions on that drive under any Linux I'm running.


• Now I'm unable to mount the XFS partition from the Arch x86_64 that replaced the i686 version on my main laptop here. Changed nothing but the OS version.


• If I try to mount the same partition the next minute under Slackware 14.1 with linux-3.17.4 (i686), it just... mounts?!

Here's the disk layout

# fdisk -l /dev/sdb

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x531843f8

Device Boot Start End Sectors Size Id Type
/dev/sdb1 8192 212991 204800 100M 83 Linux
/dev/sdb2 212992 8200191 7987200 3.8G 82 Linux swap / Solaris
/dev/sdb3 8200192 20488191 12288000 5.9G 83 Linux
/dev/sdb4 20488192 1953523711 1933035520 921.8G 83 Linux

Mount attempt as my user gave this:

$ mount /media/momedia/
mount: mount /dev/sdb4 on /media/momedia failed: Structure needs cleaning

Then as root

# mount /media/momedia/
mount: wrong fs type, bad option, bad superblock on /dev/sdb4,
 missing codepage or helper program, or other error

 In some cases useful info is found in syslog - try
 dmesg | tail or so.

With dmesg :

# dmesg | tail
[274136.490862] sd 9:0:0:0: [sdb] 1953525168 512-byte logical blocks: 

(1.00 TB/931 GiB)
[274136.490876] sd 9:0:0:0: [sdb] 4096-byte physical blocks
[274136.491965] sd 9:0:0:0: [sdb] Write Protect is off
[274136.491980] sd 9:0:0:0: [sdb] Mode Sense: 43 00 00 00
[274136.493079] sd 9:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[274136.519478] sdb: sdb1 sdb2 sdb3 sdb4
[274136.523459] sd 9:0:0:0: [sdb] Attached SCSI disk
[274162.463851] XFS (sdb4): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled!
 Use of these features in this kernel is at your own risk!
[274162.463864] XFS (sdb4): Superblock has unknown read-only compatible features (0x1) enabled.
[274162.463869] XFS (sdb4): Attempted to mount read-only compatible filesystem read-write.
 Filesystem can only be safely mounted read only.
[274162.463878] ffff880079931000: 58 46 53 42 00 00 10 00 00 00 00 00 0e 66 f9 00 XFSB.........f..
[274162.463884] ffff880079931010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[274162.463889] ffff880079931020: ed 2d 1b 3d be 8e 4a 99 94 48 1e 50 b3 63 8a 3b .-.=..J..H.P.c.;
[274162.463895] ffff880079931030: 00 00 00 00 08 00 00 08 00 00 00 00 00 00 00 60 ...............`
[274162.463901] XFS (sdb4): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0xffffffffa0714635

[274162.463910] CPU: 0 PID: 81 Comm: kworker/0:1H Not tainted 3.10.94-1-lts310-ck #1
[274162.463915] Hardware name: Dell Inc. Inspiron 1012/00D2K7, BIOS A11 11/12/2010
[274162.463942] Workqueue: xfslogd xfs_buf_iodone_work [xfs]
[274162.463947] 0000000000000001 ffff880078f25d88 ffffffff814bec2d ffff880078f25dc8
[274162.463956] ffffffffa07172d3 ffffffffa0714635 ffffffffa0795945 ffff88007002a100
[274162.463963] 0000000000000016 ffff88007985d800 0000000000001000 ffff880078f25e08
[274162.463971] Call Trace:
[274162.463985] [<ffffffff814bec2d>] dump_stack+0x19/0x1b
[274162.464007] [<ffffffffa07172d3>] xfs_corruption_error+0x93/0xa0 [xfs]
[274162.464028] [<ffffffffa0714635>] ? xfs_buf_iodone_work+0x75/0xa0 [xfs]
[274162.464059] [<ffffffffa076da02>] xfs_sb_read_verify+0x112/0x130 [xfs]
[274162.464081] [<ffffffffa0714635>] ? xfs_buf_iodone_work+0x75/0xa0 [xfs]
[274162.464102] [<ffffffffa0714635>] xfs_buf_iodone_work+0x75/0xa0 [xfs]
[274162.464112] [<ffffffff8107558a>] process_one_work+0x17a/0x4e0
[274162.464120] [<ffffffff81076093>] worker_thread+0x123/0x430
[274162.464128] [<ffffffff814c2dc3>] ? preempt_schedule+0x43/0x60
[274162.464137] [<ffffffff81075f70>] ? manage_workers.isra.8+0x290/0x290
[274162.464144] [<ffffffff8107c6f0>] kthread+0xc0/0xd0
[274162.464152] [<ffffffff8107c630>] ? kthread_worker_fn+0x170/0x170
[274162.464161] [<ffffffff814cbe48>] ret_from_fork+0x58/0x90
[274162.464168] [<ffffffff8107c630>] ? kthread_worker_fn+0x170/0x170
[274162.464174] XFS (sdb4): Corruption detected. Unmount and run xfs_repair
[274162.464193] XFS (sdb4): SB validate failed with error 22.

file -s identifies the filesystem neat and clear

[root@gwenael ~]# file -s /dev/sdb4
/dev/sdb4: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)

I checked the data at the begining of the partition and find it neat (but I'm no expert when it comes to hex)

[root@gwenael ~]# dd if=/dev/sdb4 bs=512 count=64 iflag=direct | hexdump -C
64+0 records in
64+0 records out
32768 bytes (33 kB) copied, 0.0252469 s, 1.3 MB/s
00000000 58 46 53 42 00 00 10 00 00 00 00 00 0e 66 f9 00 |XFSB.........f..|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 ed 2d 1b 3d be 8e 4a 99 94 48 1e 50 b3 63 8a 3b |.-.=..J..H.P.c.;|
00000030 00 00 00 00 08 00 00 08 00 00 00 00 00 00 00 60 |...............`|
00000040 00 00 00 00 00 00 00 61 00 00 00 00 00 00 00 62 |.......a.......b|
00000050 00 00 00 01 03 99 be 40 00 00 00 04 00 00 00 00 |.......@........|
00000060 00 01 cc df bc a5 10 00 02 00 00 08 6d 6f 6d 65 |............mome|
00000070 64 69 61 73 00 00 00 00 0c 0c 09 03 1a 00 00 19 |dias............|
00000080 00 00 00 00 00 03 f8 00 00 00 00 00 00 00 01 22 |..............."|
00000090 00 00 00 00 09 77 78 90 00 00 00 00 00 00 00 00 |.....wx.........|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000000b0 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 |................|

Next mount attempt, output changed back to what it was from my user

# mount -t xfs /dev/sdb4 /media/momedia/
mount: mount /dev/sdb4 on /media/momedia failed: Structure needs cleaning

Safe check finds the superblock

# xfs_repair -n /dev/sdb4
Phase 1 - find and verify superblock...
Phase 2 - using internal log
 - zero log...
 - scan filesystem freespace and inode maps...
 - found root inode chunk
 <SNIP SNIP>
 - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
Maximum metadata LSN (1:402600) is ahead of log (1:8).
Would format log to cycle 4.

Since it does not mount, I run xfs_repair /dev/sdb4 with the same output as above but

Phase 5 - rebuild AG headers and trees...
 - reset superblock...

Yet I can't mount it either

# mount -t xfs /dev/sdb4 /media/momedia/
mount: wrong fs type, bad option, bad superblock on /dev/sdb4,
 missing codepage or helper program, or other error

I then runned xfs_repair /dev/sdb4 with the same result.

First time I meet such a sensitive FS so, do you know what can I do to have this mount in a more standard/compatible way?

EDITED to show the full system log upon mount command.
Also, mouting it read-only as per the log's advice fails on Arch:

# mount -t xfs -o ro /dev/sdb4 /mnt/tmp/
mount: mount /dev/sdb4 on /mnt/tmp failed: Structure needs cleaning

mkfs.xfs (starting with version 3.2.4 of xfsprogs) recently defaulted to version 5 superblock, with lots of new enhancements like metadata CRC checksums. Version 5 superblock requires a 3.16 kernel or better. This error is typical, you're trying to mount the volume on a kernel which doesn't support v5 superblocks, i. e. with a version prior to 3.16.

Be careful, when using recent versions of xfsprogs with older kernels. You'll have to use these options to create a v4 filesystem:

mkfs.xfs -m crc=0,finobt=0 /your/device

Notice that the finobt option may not be necessary.

On the other hand, in case you need to check or repair your filesystem, it's always better to use the latest xfsprogs release. So I'd advise to use xfsprogs in a version as high as possible, with the caveat that you may need to use the previous command line when creating a new filesystem to be sure it's compatible with your running kernel.

Additional info about RH/CentOS 7.x

There is an exception:RedHat/CentOS v. 7.x provide xfsprogs in a version which supports XFS v5, and their kernels (even though the default version pretends to be 3.10.x) also supports XFS v5.

However RH/CentOS' mkfs.xfs has been patched to default to XFS v4. So if you're running RedHat/CentOS v7.x, you may want to use

mkfs.xfs -m crc=1,finobt=1 /your/device

to take advantage of the new features.