Re: XFS reflink vs ThinLVM

[Gionatan Danti <g.danti@assyoma.it>]

Il 19-01-2020 00:06 Darrick J. Wong ha scritto:
> 4GB / 1M extents == 4096, which is probably the fs blocksize :)

Yes, it did the same observation: due to random allocation, the 
underlying vdisk had block-sized extents.

> I wonder, do you get different results if you set an extent size hint
> on the dir before running fio?

Yes: setting extsize at 128K strongly reduces the amount of allocated 
extents (eg: 4M / 128K = 32K extents). A similar results can be obtained 
tapping in cowextsize, by cp --reflink the original file. Any subsequent 
4K write inside the guest will cause a 128K CoW allocation (with default 
setting) on the backing file.

However, while *much* better, it is my understanding that XFS reflink is 
a variable-length process: as any extents had to be scanned/reflinked, 
the reflink time is not constant. Meanwhile it is impossible to 
read/write from the reflinked file. Am I right?

On the other side thinlvm snapshots, operating on block level, are a 
(more-or-less) constant-time operation, causing much less disruption in 
the normal IO flow of the guest volumes.

I don't absolutely want to lessen reflink usefulnes; rather, it is an 
extremely useful feature which can be put to very good use.

> I forgot(?) to mention that if you're mostly dealing with sparse VM
> images then you might as well set a extent size hint and forego delayed
> allocation because it won't help you much.

This was my conclusion as well.
Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8