On 01/31/2011 03:17 PM, Eric Blake wrote: >> The default is --efficient-sparse=auto, and for symmetry, >> I've provided --efficient-sparse=never, in case someone finds >> a reason to want to skip the ioctl. > > Conversely, what happens if I have a file that contains large blocks of > zeros but is NOT fully sparse (plausible, since we're still facing the > fact that it is still not easy to punch holes into existing files when > data in that portion of the file is no longer needed)? Does all the new > fiemap code still have the ability for me to request that the cp code > specifically look for large blocks of zero in the source, rather than > trusting the fiemap, so that I can create a copy that is more sparse > than the original? Does that also need a tunable; and if so, should we > try to combine it into this tunable or is it orthogonal?
Maybe something like this matrix, introducing --sparse=search as a step
beyond --sparse=always to request that the (non-sparse) portions of the
input be specifically searched for possible further blocks of 0 that can
be made sparse in the destination:
--sparse=always --efficient-sparse=always
require fiemap, destination will only be as sparse as input
--sparse=search --efficient-sparse=always
require fiemap, destination might be more sparse than input
--sparse=always --efficient-sparse=auto
if fiemap is supported, destination will be as sparse as input
if fiemap is not supported, destination might be more sparse
--sparse=search --efficient-sparse=auto
destination might be more sparse than input
--sparse=auto --efficient-sparse=always
if input is sparse, require fiemap, destination will match input
sparseness
--sparse=auto --efficient-sparse=auto
destination will be sparse if input was sparse; if fiemap is
supported then destination will be equally sparse, otherwise, it might
be more sparse than the input
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
