Il 15-01-2020 18:45 Gionatan Danti ha scritto:
Let me briefly describe the expected workload: thinly provisioned virtual image storage. The problem with "plain" sparse file (ie: without extsize hint) is that, after some time, the underlying vdisk file will be very fragmented: consecutive physical blocks will be assigned to very different logical blocks, leading to sub-par performance when reading back the whole file (eg: for backup purpose). I can easily simulate a worst-case scenario with fio, issuing random write to a pre-created sparse file. While the random writes complete very fast (because they are more-or-less sequentially written inside the sparse file), reading back that file will have very low performance: 10 MB/s vs 600+ MB/s for a preallocated file.
I would like to share some other observation/results, which I hope can be useful for other peoples.
Further testing shows that "cp --reflink" an highly fragmented files is a relatively long operation, easily in the range of 30s or more, during which the guest virtual machine is basically denied any access to the underlying virtual disk file.
While the number of fragments required to reach reflink time of 30+ seconds is very high, this would be a quite common case when using thinly provisioned virtual disk files. With sparse file, any write done at guest OS level has a very good chance to create its own fragment (ie: allocating a discontiguous chunk as seen by logical/physical block mapping), leading to very fragmented files.
So, back to main topic: reflink is an invaluable tool, to be used *with* (rather than instead of) thin lvm:
- thinlvm is the right tool for taking rolling volume snapshot; - reflink is extremely useful for "on-demand" snapshot of key files. Thank you all for the very detailed and useful information you provided. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx GPG public key ID: FF5F32A8
