Red Hat Bugzilla – Bug 1444166
mkfs.xfs ignores sunit=0, swidth=0 settings when creating new XFS filesystem.
Last modified: 2018-04-10 11:08:51 EDT
Description of problem: When trying to create a new xfs filesystem on a RHEL 7.3 machine with the sunit and swidth values manually set to 0, filesystem is made with those values set to sunit=16,swidth=10752. This only happens on a particular Hitachi Lun directly attached via SAN. # mkfs.xfs -d sunit=0,swidth=0 /dev/`uname -n`vg/lv Version-Release number of selected component (if applicable): xfsprogs-3.2.2-2.el7.x86_64 kernel-version: kernel-3.10.0-514.6.1.el7.x86_64 Thu Mar 2 11:01:29 2017 How reproducible: Customer can reproduce every time they make a new xfs filesystem on a Hitachi Lun directly attached via SAN. Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: HITACHI Model: OPEN-V Rev: 8001 Type: Direct-Access ANSI SCSI revision: 05 Steps to Reproduce: 1. Create new lv on existing vg with lvcreate 2. mkfs.xfs -d sunit=0,swidth=0 <lv> See xfs_example.png attached to bug for a screenshot of this process. Customer can repeat the above steps on their Hitachi Lun and mkfs.xfs seems to ignore or auto-calculate the sunit and swidth values based upon that underlying hardware rather than the options passed into mkfs.xfs. Customer has attempted this process in a VM and is unable to replicate in that environment. Actual results: # lvcreate -L 32m -n wra1 `uname -n`vg00 Logical volume "wra1" created. root@s51r010:/root # mkfs.xfs -d sunit=0,swidth=0 /dev/`uname -n`vg00/wra1 meta-data=/dev/s51r010vg00/wra1 isize=256 agcount=2, agsize=4096 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=8192, imaxpct=25 = sunit=16 swidth=10752 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=768, version=2 = sectsz=512 sunit=16 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Expected results: # mkfs.xfs -d sunit=0,swidth=0 /dev/`uname -n`vg00/wra1 meta-data=/dev/s51r010vg00/wra1 isize=256 agcount=2, agsize=4096 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=8192, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=768, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Additional info:
Please try: mkfs.xfs -d noalign .... From the manpage: noalign This option disables automatic geometry detection and creates the filesystem without stripe geometry alignment even if the underlying storage device provides this information. It would be nice if specifying 0 had this same effect, but in the short term I believe that the "noalign" option will do what the customer wants. Can you confirm? Thanks, -Eric
We met this problem before when we ran xfstests striped storage device, and I use "-d sunit=0,swidth=0,noalign" to keep away that problem. It works, but we don't suggest to do that except you know what you want. Thanks, Zorro
Yes, I also wonder why there is a need to override the storage-specified geometry. Still, if it is what is needed, it should be possible. Anyway, Scott, can you confirm that the workaround will resolve the issue in the short term? Thanks, -Eric
The reason the code is behaving this way, btw, is that the sunit & swidth variables are set to 0 in the code to mean "not specified." So, specifying them as zero on the commandline currently looks exactly the same as if it were not specified at all, and automatic detection still happens. Scott, where do you want to go with this bug & the associated case. Is the customer happy with the noalign option?
I sent a patch upstream for this, [PATCH] mkfs.xfs: allow specification of 0 data stripe width & unit ... but I've not merged it upstream yet. Still, a patch is available.
Looks like a straightforward patch to me.
commit 746d40a73162f942f63f6a2f612f491d107b9824 Author: Eric Sandeen <sandeen@redhat.com> Date: Thu Jul 20 10:51:34 2017 -0500 mkfs.xfs: allow specification of 0 data stripe width & unit The "noalign" option works for this too, but it seems reasonable to allow explicit specification of stripe unit and stripe width to 0; today, doing so today makes the code think it's unspecified, and so it goes ahead and detects stripe geometry and sets it in the superblock. That's unexpected and surprising. Create a new flag that tracks whtether a geometry option has been specified, and if it's set along with 0 values, treat it the same as if "noalign" had been specified. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0847