From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br1A8-0007tj-4F for qemu-devel@nongnu.org; Mon, 03 Oct 2016 07:12:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1br1A5-0002P1-Sa for qemu-devel@nongnu.org; Mon, 03 Oct 2016 07:11:59 -0400 Date: Mon, 3 Oct 2016 12:11:46 +0100 From: "Daniel P. Berrange" Message-ID: <20161003111146.GG13491@redhat.com> Reply-To: "Daniel P. Berrange" References: <598de7ff27e32fcb1b7f677f40fb8da4f0a1f512.1475434971.git.tgolembi@redhat.com> <20161003085213.GA13491@redhat.com> <20161003124557.76781119@fiorina> <20161003105259.GF13491@redhat.com> <20161003130707.6fcfd9dc@fiorina> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161003130707.6fcfd9dc@fiorina> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] raw-posix: add 'offset' and 'size' options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?VG9tw6HFoSBHb2xlbWJpb3Zza8O9?= Cc: qemu-block@nongnu.org, Kevin Wolf , qemu-devel@nongnu.org, Max Reitz On Mon, Oct 03, 2016 at 01:07:07PM +0200, Tom=C3=A1=C5=A1 Golembiovsk=C3=BD= wrote: > On Mon, 3 Oct 2016 11:52:59 +0100 > >=20 > > > > > + > > > > > + if (((bs->drv !=3D &bdrv_file) || !bs->read_only) && =20 > > > >=20 > > > > Why the check against bdrv_file ? =20 > > >=20 > > > To limit it only to files. Maybe there is better way to do that? Th= e > > > devices have a nasty habit to change the size. Sure, this can happe= n to > > > file too, e.g. if somebody truncates the file outside QEMU. But tha= t's > > > rather a bad behaviour. For devices changing the size may be perfec= tly > > > valid operation, e.g. replacing CD in drive or card in a card reade= r. =20 > >=20 > > 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. >=20 > The question is then, what to do when the underlying device changes? Th= e > 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.= =20 > > >=20 > > > I still plan to do that, but I didn't feel confident enough to do i= t in > > > the first run. > > >=20 > > > We need to decide what is the correct behaviour here first. Since t= he > > > 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: > > >=20 > > > 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. > > >=20 > > > 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 si= ze 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. =20 > >=20 > > We should not make assumptions about what is a valid or invalid usage= , > > as QEMU doesn't have enough knowledge to do that correctly. > >=20 > > 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. >=20 > 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 don= e > from outside with 'qemu-img resize'? Truncate is something run from the host - guests are certainly not allowe= d 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 --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr= / :|