On 2/2/17 10:00 AM, Eric Sandeen wrote:
> On 2/2/17 1:55 AM, Christoph Hellwig wrote:
>> Hi all,
>>
>> below are backports up to 4.10-rc6 for XFS. I've selected all clear
>> bugfixes for reported bugs. I've skipped the finobt space reservation
>> patch for now - I think it is stable material, but I want it to settle
>> a bit more first.
>
> fwiw, the finobt space reservation thing also seems to be doing something
> odd with allocation on striped storage, unless I'm missing something.
>
> If I stick an xfs_bmap -v into generic/108 after we write the initial
> file, we find that it's not stripe aligned with that patch in place,
> which seems unexpected. I haven't yet worked out why, was first trying
> to sort out that lvm error propagation problem...
Ok, I guess this may not be a big deal. Because this is a small filesystem
in the test, and striped, we end up with small AGs:
meta-data=/dev/mapper/vg_108-lv_108 isize=512 agcount=9, agsize=7168 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=0, rmapbt=0, reflink=0
data = bsize=4096 blocks=63488, imaxpct=25
= sunit=1024 swidth=2048 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =/dev/sdb3 bsize=4096 blocks=32768, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
each only 7168 blocks, or about 28M.
We try to do a 16M write, and xfs would like that to be stripe aligned.
I'm not quite sure why it's failing, but for a larger filesystem things
do come out aligned again. I'll keep digging but I don't think there's
any fundamental problem here, this is a weird, small filesystem.
-Eric
--
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
