'stripe width' inconsistency

'stripe width' inconsistency

[Jan]

Hello!

I hope I came to the right place here. If not, I'd appreciate a pointer to a more appropriate one.

Recently, I ran into problems mounting one of my XFS file systems. It's been a while since I used that HDD but I'm almost certain there were no problems. 'xfs_repair' complains about 'bad stripe width in superblock' but 'xfs_db' has no problems parsing the filesystem. It reports (among other information)

> unit = 8
> width = 65535
[...]
> crc = 0xe9e260b (correct)

and can also output directory/file information properly. The values for 'unit' and 'width' do seem strange but are the defaults chosen by 'mkfs.xfs'. I double checked that by running 'mkfs.xfs -Nf' on the device which yields

> data     =                       bsize=4096   blocks=976688597, imaxpct=5
>          =                       sunit=8      swidth=65535 blks

In case this is relevant: The filesystem is created on top of a LUKS container on an external USB disk. 'blockdev --getss --getpbsz --getiomin --getioopt /dev/mapper/XFS' reports

> 4096
> 4096
> 32768
> 268431360

and 'fdisk -l /dev/sdb'

> Device     Start       End   Sectors  Size Type
> /dev/sdb1  65535 976754636 976689102  3,7T Linux filesystem

I'm running a 64-bit Debian Testing, so my xfsprogs are version 4.15.1 and the kernel is 4.18. If any further information is required/helpful, I'll gladly provide it. Is there any way to "repair" the XFS or at the very least (mount it to) copy its files?

Regards, Jan

Re: 'stripe width' inconsistency

[Jan]

Hi!

It's been some time but if anybody finds this thread later on, here is how I solved the problem:

Dec 26, 2018, 12:09 AM by bug-reporter@tuta.io:

> Recently, I ran into problems mounting one of my XFS file systems. It's been a while since I used that HDD but I'm almost certain there were no problems. 'xfs_repair' complains about 'bad stripe width in superblock' but 'xfs_db' has no problems parsing the filesystem. It reports (among other information)
>
> > unit = 8
> > width = 65535
> [...]
> > crc = 0xe9e260b (correct)
>
In the end it worked to use 'xfs_db -x' to change the width to '65536'. (Actually, I used a dm snapshot so I did not have to touch the actual block device, but that was just a safety measure.) After that, I could mount the filesystem normally again. Just to be safe, I mounted it read-only, made a backup and recreated the filesystem with (manually set) sane parameters.

As a recommendation: it would be nice if such "defect" filesystems were still mountable, even if read only ;-)


Regards, Jan