Re: [Qemu-devel] [RFC PATCH 2/4] block/raw-posix: implement bdrv_zero_init

[Hu Tao]

On Tue, Nov 12, 2013 at 11:28:05AM +0100, Kevin Wolf wrote:
> Am 12.11.2013 um 08:47 hat Hu Tao geschrieben:
> > Implement bdrv_zero_init using posix_fallocate.
> > 
> > Signed-off-by: Hu Tao <address@hidden>
> > ---
> >  block/raw-posix.c | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/block/raw-posix.c b/block/raw-posix.c
> > index f6d48bb..8798599 100644
> > --- a/block/raw-posix.c
> > +++ b/block/raw-posix.c
> > @@ -1190,6 +1190,18 @@ static int64_t coroutine_fn 
> > raw_co_get_block_status(BlockDriverState *bs,
> >      return ret;
> >  }
> >  
> > +static int raw_zero_init(BlockDriverState *bs, int64_t offset, int64_t 
> > length)
> > +{
> > +    BDRVRawState *s = bs->opaque;
> > +    int64_t len = bdrv_getlength(bs);
> > +
> > +    if (offset + length < 0 || offset + length > len) {
> > +        return -1;
> > +    }
> > +
> > +    return posix_fallocate(s->fd, offset, length);
> > +}
> 
> This doesn't really initialise anything to zero. It merely preallocates
> those parts of a file that aren't allocated yet (and they happen to be
> zeroed in this case), but leaves already existing parts untouched.

Then the name is inappropriate, how about bdrv_preallocate()?

> 
> I wonder if this would be a correct implementation for a bdrv_anchor(),

Why?

> though. I also wouldn't call that full preallocation, but it might be
> useful anyway.

Wouldn't bdrv_preallocate(bs, 0, bdrv_getlength(bs)) be full
preallocation?