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

[Richard W.M. Jones]

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 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'.

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