[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of

From: Kevin Wolf
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of growing formats over non-growable protocols
Date: Thu, 7 May 2015 16:07:16 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 07.05.2015 um 15:55 hat Paolo Bonzini geschrieben:
> On 07/05/2015 15:20, Kevin Wolf wrote:
> > > Does ENOSPC over LVM (dm-linear) work at all, and who generates the
> > > ENOSPC there?
> >
> > The LVM use case is what oVirt uses, so I'm pretty sure that it works.
> > I'm now sure who generates the ENOSPC, but it's not qemu anyway. If I
> > had to guess, I'd say that the kernel block layer might just forbid
> > writing after EOF for any block device.
> Indeed, though it's VFS (blkdev_write_iter in fs/block_dev.c) and not
> the block layer.  It looks like we need this:
> diff --git a/block/block-backend.c b/block/block-backend.c
> index 93e46f3..e54c433 100644
> --- a/block/block-backend.c
> +++ b/block/block-backend.c
> @@ -461,7 +461,7 @@ static int blk_check_byte_request(BlockBackend *blk, 
> int64_t offset,
>      }
>      if (offset > len || len - offset < size) {
> -        return -EIO;
> +        return -ENOSPC;
>      }

This is not right for two reasons: The first is that this is
BlockBackend code and it wouldn't even take effect for the qcow2 case
where we're writing past EOF only on the protocol layer. The second is
that -ENOSPC is only for writes and not for reads.

For the protocol level, bdrv_aligned_preadv() has code to handle reads
past EOF if bs->zero_beyond_eof is set. This is always the case, except
for qcow2, which has the snapshot VM state after EOF, so the driver is
called for that.

For writes, the driver is always called. The expectiation is that beyond
EOF it resizes the image file if it can, and returns -ENOSPC if it can't.
We could change this to have a check directly in bdrv_aligned_pwrite()
and then drivers would have to advertise whether they can extend a file
beyond EOF or not so we know whether to apply the check or not
(essentially the growable flag that Max wants to add), but I'm not sure
what we would win with that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]