Re: [Qemu-block] [Qemu-devel] [PATCH] raw-posix: add 'offset' and 'size' options

[Daniel P. Berrange]

On Mon, Oct 03, 2016 at 01:07:07PM +0200, Tomáš Golembiovský wrote:
> On Mon, 3 Oct 2016 11:52:59 +0100
> > 
> > > > > +
> > > > > +    if (((bs->drv != &bdrv_file) || !bs->read_only) &&    
> > > > 
> > > > Why the check against bdrv_file ?  
> > > 
> > > To limit it only to files. Maybe there is better way to do that? The
> > > devices have a nasty habit to change the size. Sure, this can happen to
> > > file too, e.g. if somebody truncates the file outside QEMU. But that's
> > > rather a bad behaviour. For devices changing the size may be perfectly
> > > valid operation, e.g. replacing CD in drive or card in a card reader.  
> > 
> > The raw driver is usable over any storage backend (file, rbd, iscsi,
> > etc, etc) and it is valid to want to use a offset/size parameter in
> > combination with any of them. So we should not restrict it to just
> > files.
> 
> The question is then, what to do when the underlying device changes? The
> size/offset may not be valid at that point anymore.

The underlying device shouldn't be changing in size without that change
going through the raw format driver

> > > > Why did you restrict it to read-only instead of adding the offset logic
> > > > to the write & truncate methods. IMHO if we're going to add this feature
> > > > we should make it work in all scenarios, not just do 1/2 the job.  
> > > 
> > > I still plan to do that, but I didn't feel confident enough to do it in
> > > the first run.
> > > 
> > > We need to decide what is the correct behaviour here first. Since the
> > > image we're working with is contained in some larger unit it cannot be
> > > resized freely. There are two option that come to my mind:
> > > 
> > > 1) block truncate/grow completely,
> > > 2) allow image to be truncated and grown only if the new size does not
> > >    go over the original size.
> > > 
> > > If we go with the second option then I have a another question. How
> > > strict is (or should be) qemu about the sizes being block aligned? I'm
> > > still little bit fuzzy on that. Somewhere it is assumed that the size is
> > > multiple of 512, sometimes qemu automatically rounds up if it isn't and
> > > sometimes it seems to me that the size can be arbitrary.  
> > 
> > We should not make assumptions about what is a valid or invalid usage,
> > as QEMU doesn't have enough knowledge to do that correctly.
> > 
> > IOW, we should just allow truncate with no restrictions. It is up to the
> > calling app to figure out whether truncate makes sense or not.
> 
> Maybe I'm missing something here. Can the truncate operation be somehow
> initiated from inside the VM, or is that only something that can be done
> from outside with 'qemu-img resize'?

Truncate is something run from the host - guests are certainly not allowed
to trigger truncate, as that would let you inflict a denial of service on
the host by consuming  disk space they should not be allowed.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|