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

["Tomáš Golembiovský" <tgolembi@redhat.com>]

On Tue, 4 Oct 2016 10:57:49 +0200
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 03.10.2016 um 13:07 hat Tomáš Golembiovský geschrieben:
> > > > > > +    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.  
> 
> Just to clear up some confusion here: There are the file/host_device/...
> protocol drivers, which only access local files. These are implemented
> in raw-posix.c, i.e. the file that this patch is touching. raw-win32.c
> implements the same kind of file access for Windows.
> 
> And then there is the raw image format driver, which is raw_bsd.c. This
> one is what is layered on top of any of the protocol drivers, including
> raw-posix, raw-win32 and all the network protocols.
> 
> This is why implementing the feature in the raw format driver would make
> it so much more useful. You could use it with any backend then.
> 

Thanks Kevin, this really helped. I have to admit the naming is quite
confusing.


> > > > 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.    
> 
> Traditionally, the qemu block layer worked in 512 byte units and you
> still see places where this is true. But we're in a process of
> converting things to use bytes everywhere (which saves a lot of
> conversion back and forth and simplifies the code), and the basic
> read/write functions in the primary block drivers (raw, qcow2, file) can
> all work with byte granularity today.

Again thanks for clearing that up a bit.


    Tomas

-- 
Tomáš Golembiovský <tgolembi@redhat.com>