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@xxxxxxxxxx - info@xxxxxxxxxx GPG public key ID: FF5F32A8
