On Fri, Aug 22, 2014 at 05:00:08PM +0100, Richard W.M. Jones wrote: > On Fri, Aug 22, 2014 at 05:53:22PM +0200, Kevin Wolf wrote: > > Am 22.08.2014 um 17:34 hat Richard W.M. Jones geschrieben: > > > On Fri, Aug 22, 2014 at 05:22:33PM +0200, Kevin Wolf wrote: > > > > It's still useful because it happens to reduce the overhead in most > > > > implementations and it's a relatively quick operation, but the best way > > > > I know of to actually _fully_ preallocate is still writing zeros. Which > > > > of the two the user wants, is a decision that qemu can't make for them. > > > > > > This is a difficult situation. Possibly the choice is between > > > > > > - efficiently make the file fully allocated, that works in the vast > > > majority of cases, but don't go crazy (ie. fallocate) > > > > > > - really really try as hard as possible to make sure that future > > > allocations will never fail (ie. write random non-zero data to the > > > file) > > > > > > Note that neither of these is the preallocation=... option as > > > specified in this patch. > > > > Isn't the first one exactly preallocation=falloc and the second is > > preallocation=full, except that we're not writing non-zero blocks? (And > > probably shouldn't, because that would change the content.) > > Well no for a few reasons: > > 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. > > 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? Regards, Hu > > TBH I think this whole thing is overkill and we should just have a > preallocation option that works like in libvirt. Anything else is > silly [see above] or pushes the problem to upper layers that are in no > position to make that decision. > > Remember that the upper layer is probably not even running on the same > machine. It has no knowledge of the backing LUN. It doesn't know > about the hypervisor kernel (ie. if fallocate will fail). > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v