Re: [Qemu-devel] [PATCH 6/7] block/raw-posix: call plain fallocate in handle_aiocb_write_zeroes

[Denis V. Lunev]

On 30/01/15 01:50, Max Reitz wrote:
> On 2015-01-28 at 13:38, Denis V. Lunev wrote:
> > There is a possibility that we are extending our image and thus writing
> > zeroes beyond the end of the file. In this case we do not need to care
> > about the hole to make sure that there is no data in the file under
> > this offset (pre-condition to fallocate(0) to work). We could simply 
> > call
> > fallocate(0).
> >
> > This improves the performance of writing zeroes even on really old
> > platforms which do not have even FALLOC_FL_PUNCH_HOLE.
> >
> > Before the patch do_fallocate was used when either
> > CONFIG_FALLOCATE_PUNCH_HOLE or CONFIG_FALLOCATE_ZERO_RANGE are defined.
> > Now the story is different. CONFIG_FALLOCATE is defined when Linux
> > fallocate is defined, posix_fallocate is completely different story
> > (CONFIG_POSIX_FALLOCATE). CONFIG_FALLOCATE is mandatory prerequite
> > for both CONFIG_FALLOCATE_PUNCH_HOLE and CONFIG_FALLOCATE_ZERO_RANGE
> > thus we are on the safe side.
> >
> > Signed-off-by: Denis V. Lunev <address@hidden>
> > CC: Max Reitz <address@hidden>
> > CC: Kevin Wolf <address@hidden>
> > CC: Stefan Hajnoczi <address@hidden>
> > CC: Peter Lieven <address@hidden>
> > CC: Fam Zheng <address@hidden>
> > ---
> >   block/raw-posix.c | 14 +++++++++++++-
> >   1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/block/raw-posix.c b/block/raw-posix.c
> > index 2e24829..3db911a 100644
> > --- a/block/raw-posix.c
> > +++ b/block/raw-posix.c
> > @@ -147,6 +147,7 @@ typedef struct BDRVRawState {
> >       bool has_discard:1;
> >       bool has_write_zeroes:1;
> >       bool discard_zeroes:1;
> > +    bool has_fallocate;
> >       bool needs_alignment;
> >   } BDRVRawState;
> >   @@ -452,6 +453,7 @@ static int raw_open_common(BlockDriverState 
> > *bs, QDict *options,
> >       }
> >       if (S_ISREG(st.st_mode)) {
> >           s->discard_zeroes = true;
> > +        s->has_fallocate = true;
> >       }
> >       if (S_ISBLK(st.st_mode)) {
> >   #ifdef BLKDISCARDZEROES
> > @@ -902,7 +904,7 @@ static int translate_err(int err)
> >       return err;
> >   }
> >   -#if defined(CONFIG_FALLOCATE_PUNCH_HOLE) || 
> > defined(CONFIG_FALLOCATE_ZERO_RANGE)
> > +#ifdef CONFIG_FALLOCATE
> >   static int do_fallocate(int fd, int mode, off_t offset, off_t len)
> >   {
> >       do {
> > @@ -980,6 +982,16 @@ static ssize_t 
> > handle_aiocb_write_zeroes(RawPosixAIOData *aiocb)
> >       }
> >   #endif
> >   +#ifdef CONFIG_FALLOCATE
> > +    if (s->has_fallocate && aiocb->aio_offset >= 
> > bdrv_getlength(aiocb->bs)) {
> > +        int ret = do_fallocate(s->fd, 0, aiocb->aio_offset, 
> > aiocb->aio_nbytes);
> > +        if (ret == 0 || ret != -ENOTSUP) {
> > +            return ret;
> > +        }
> > +        s->has_fallocate = false;
> > +    }
> > +#endif
> > +
> >       return -ENOTSUP;
> >   }
>
> Now that you do have has_fallocate, I think you should be using it in 
> patch 5 as well. So I think you should either you make this patch add 
> it in the area touched by patch 5, or you introduce has_fallocate in 
> patch 5 already and use it there.
>
> Max
OK. No problem. I do not think that it is ever possible, but
why not?

I will reorder these patches in the patchset to minimize changes.