On Tue, Jul 31, 2018 at 7:32 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
> This seems suboptimal. Basically this is a 750G thin volume. I don't
> have a plain partition on a device handy to try this out but I'm
> pretty certain the default is 4 AG's in that case, so I'm confused why
> by default 33 AGs are created on a thin volume. The LVM volume group
> is on a dmcrypt PV.
>
>
> xfsprogs-4.15.1-1.fc28.x86_64
> lvm2-2.02.177-5.fc28.x86_64
> kernel-4.17.11-200.fc28.x86_64
>
>
> = sunit=128 swidth=1024 blks
This also seems screwy for a single non-raid device. I wonder if
there's something goofy happening with device mapper that's giving the
wrong information to XFS.
I just built xfsprogs 4.17 from git and I get different unexpected results:
[chris@f28s mkfs]$ sudo ./mkfs.xfs -V
mkfs.xfs version 4.17.0
[chris@f28s mkfs]$ sudo ./mkfs.xfs /dev/mapper/4vg-nukeit
mkfs.xfs: Use the -f option to force overwrite.
[chris@f28s mkfs]$ sudo ./mkfs.xfs -f /dev/mapper/4vg-nukeit
meta-data=/dev/mapper/4vg-nukeit isize=512 agcount=4, agsize=49152000 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=0
data = bsize=4096 blocks=196608000, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=96000, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
[chris@f28s mkfs]$
The agcount, sunit and swidth are what I expect, but sectsz=512 is
not. The device has a 4096 byte physical sector. And this is being
reported by 'lsblk' as a 4096 byte physical sector with 512 byte
logical sector (it is a 512e drive). The 4.15.0 Fedora built xfsprogs
got this right, but 4.17.0 as built is not.
:shrug:
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
