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/ :|
