From: Jan <bug-reporter@tuta.io>
To: Linux Xfs <linux-xfs@vger.kernel.org>
Subject: 'stripe width' inconsistency
Date: Wed, 26 Dec 2018 00:09:21 +0100 (CET) [thread overview]
Message-ID: <LUbcIN3--3-1@tuta.io> (raw)
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
next reply other threads:[~2018-12-25 23:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-25 23:09 Jan [this message]
2019-04-25 14:34 ` 'stripe width' inconsistency Jan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=LUbcIN3--3-1@tuta.io \
--to=bug-reporter@tuta.io \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.