Re: [Qemu-devel] [PATCH v12 0/6] qcow2, raw: add preallocation=full and preallocation=falloc

[Hu Tao]

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