On Mon, Aug 25, 2014 at 01:18:30PM +0800, Hu Tao wrote: > On Fri, Aug 22, 2014 at 05:00:08PM +0100, Richard W.M. Jones wrote: > > What is proposed to be called 'preallocation=falloc' should fall back > > to other methods (eg. writing random, writing zeroes). It should > > also be called something more useful like 'preallocation=best'. > > What if user cares about time(writing zeroes or non-zeroes is > time-consuming) and wants falloc only sometimes? I think this is the > main difference between preallocation=falloc and preallocation=full.
So fallocate fails, and then what? The user wants something which just works, not something which will fail inexplicably. As a rule of thumb, end users and higher layers of the virt stack have absolutely no idea about the details of what happens in qemu, and requiring to have this knowledge is impossible. If it takes too long, that's a performance problem to look into -- fixed by using a filesystem that uses extents. > > What is proposed to be called 'preallocation=full' should not write > > just zeroes. It needs to write random data since otherwise lower > > layers could discard those writes and that would mean metadata > > allocations could still take time (or fail). It could also be called > > something more useful, say, 'preallocation=tryveryhard'. > > I agree with you on this one, but does it need to be random? does ~0 work? As I said in the other part of this email, I don't actually think we should implement such an option. A simple preallocation option that just works most of the time is fine. However since you asked, ~0 will not work. For a long time SANs have been able to detect the same data in two blocks and combine them, a process called 'deduplication'. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
