Gionatan Danti
2017-12-27 18:44:33 UTC
Hi all,
there is any method to preallocate any space to a specific thin volume,
other that writing to it? If not, it is in the todo list?
I know a similar question was raised in the past, but it was in the
different context of reserverd space - ie to be "sure" about a volume
not filling up. I understand this can not be done in the current device
mapper context.
This time I wonder about fallocate as a performance optimization,
heading to reduced thin-volume fragmentation. For example, a thin
volume-backed virtual machine image can be entirely allocated with
mostly contiguous data chunks. Any snapshot will obviously allocates
random data chunks, but with careful scheduling its effect on data
fragmentation should be limited/contained.
Today, to accomplish that, I need to write out *all* data chunks from
the virtual machine itself. This is a time-consuming and error prone
process. A simpler "volume-preallocation" and/or an "fallocate-passing"
facility would facilitate this process.
And yes - I know POSIX-fallocate is all about *assuring* than
application will not face an ENOSP condition, rather than a fast-zeroing
surrogate. However, in the framework of thin volume this is basically
impossible to guarantee. On the other hand, its performance enhancing
implications are significan enough they should not be overlooked.
Thanks.
there is any method to preallocate any space to a specific thin volume,
other that writing to it? If not, it is in the todo list?
I know a similar question was raised in the past, but it was in the
different context of reserverd space - ie to be "sure" about a volume
not filling up. I understand this can not be done in the current device
mapper context.
This time I wonder about fallocate as a performance optimization,
heading to reduced thin-volume fragmentation. For example, a thin
volume-backed virtual machine image can be entirely allocated with
mostly contiguous data chunks. Any snapshot will obviously allocates
random data chunks, but with careful scheduling its effect on data
fragmentation should be limited/contained.
Today, to accomplish that, I need to write out *all* data chunks from
the virtual machine itself. This is a time-consuming and error prone
process. A simpler "volume-preallocation" and/or an "fallocate-passing"
facility would facilitate this process.
And yes - I know POSIX-fallocate is all about *assuring* than
application will not face an ENOSP condition, rather than a fast-zeroing
surrogate. However, in the framework of thin volume this is basically
impossible to guarantee. On the other hand, its performance enhancing
implications are significan enough they should not be overlooked.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8