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