On Wed, Aug 30, 2017 at 9:54 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > On 8/29/17 11:18 PM, Donald Douwsma wrote: >> When sunit and swidth are used mkfs.xfs tries to avoid all allocation >> groups aligning on the same stripe and will attempt to stagger them >> across the stripes that make up swidth. If there is only one stripe >> then there is no benefit in this optimisation. >> >> $ truncate -s10G xfs_10G_su256k_sw1.image >> $ mkfs.xfs -d su=256k,sw=1 xfs_10G_su256k_sw1.image >> meta-data=xfs_10G_su256k_sw1.image isize=512 agcount=16, agsize=163776 blks >> = sectsz=512 attr=2, projid32bit=1 >> = crc=1 finobt=0, sparse=0 >> data = bsize=4096 blocks=2620416, imaxpct=25 >> = sunit=64 swidth=64 blks >> naming =version 2 bsize=4096 ascii-ci=0 ftype=1 >> log =internal log bsize=4096 blocks=2560, version=2 >> = sectsz=512 sunit=64 blks, lazy-count=1 >> realtime =none extsz=4096 blocks=0, rtextents=0 >> >> A side effect of the optimisation is that the size adjustment used to stager >> the allocation groups causes the last sunit of storage to be unused. Actually it shrinks the agsize by one sunit, leading to the discrepancy of sunit * agcount, for the above example 4MB. >> $ echo $((2620416*4096)) >> 10733223936 >> $ ls -l xfs_10G_su256k_sw1.image >> -rw-rw-r--. 1 test test 10737418240 Aug 30 10:54 xfs_10G_su256k_sw1.image >> >> Skip this optimisation when sunit == swidth. >> >> Signed-off-by: Donald Douwsma <ddouwsma@xxxxxxxxxx> > > Interesting. Yeah, I suppose this makes sense, though I'm surprised > anyone would notice. :) Sysadmins see the dependency and worry that something went wrong. If you run xfs_growfs on the mounted volume it creates a tiny allocation group to add this space in, which adds to the confusion. The broader question is what should mkfs be doing when this optimisation is active. The space could be added to the last AG, but I think silently dropping it is not ideal. -- 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