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

[Kevin Wolf]

Am 22.08.2014 um 16:20 hat Daniel P. Berrange geschrieben:
> On Fri, Aug 22, 2014 at 03:13:31PM +0200, Kevin Wolf wrote:
> > Am 22.08.2014 um 14:25 hat Richard W.M. Jones geschrieben:
> > > 
> > > On Mon, Jul 28, 2014 at 04:48:46PM +0800, Hu Tao wrote:
> > > > ping...
> > > > 
> > > > All the 6 patches have reviewed-by now.
> > > > 
> > > > On Fri, Jul 11, 2014 at 02:09:57PM +0800, Hu Tao wrote:
> > > > > This series adds two preallocation mode to qcow2 and raw:
> > > > > 
> > > > > Option preallocation=full preallocates disk space for image by writing
> > > > > zeros to disk, this ensures disk space in any cases.
> > > > > 
> > > > > Option preallocation=falloc preallocates disk space by calling
> > > > > posix_fallocate(). This is faster than preallocation=full.
> > > 
> > > Sorry if this was discussed before, but why would anyone use
> > > preallocation=full if preallocation=falloc was possible?
> > > 
> > > Shouldn't preallocation=full simply use posix_fallocate if it's
> > > available, and fall back to writing zeroes if not?
> > 
> > posix_fallocate() is basically metadata preallocation on the file
> > system level. If any lower levels involve allocations as well, does
> > posix_fallocate() allocate them there?
> 
> Well the man page says
> 
>   "After a successful call to posix_fallocate(), subsequent writes to
>    bytes in the specified range are guaranteed not to fail because of
>    lack of disk space."
> 
> Which seems like it is what users would want when they ask for
> preallocate=full. So I'm not seeing the benefit of instead being
> able to ask to write zeros would bring.

This is what the spec says. There are two problems with it:

1. The actual implementation doesn't do what the spec says. As Rich's
   test shows (and I expected), the preallocation stays on the
   filesystem level and isn't propagated to lower levels.

2. It's also not what most users want. They don't use preallocation
   because they are afraid of running out of disk space, but because
   they want performance. What they are looking for is "subsequent
   writes to bytes in the specified range are guaranteed to require no
   metadata updates". But this is neither what the spec promises you nor
   (afaik) what actual implementations do.

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.

Kevin