From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm1r4-0000iI-9Y for qemu-devel@nongnu.org; Tue, 13 Oct 2015 11:51:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm1qy-0005Dy-3v for qemu-devel@nongnu.org; Tue, 13 Oct 2015 11:51:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm1qx-0005Dm-S3 for qemu-devel@nongnu.org; Tue, 13 Oct 2015 11:51:04 -0400 References: <1444446115-3796-1-git-send-email-crosthwaite.peter@gmail.com> <561BD814.5090005@redhat.com> <561BDF26.4070405@redhat.com> <561BFB42.1080902@redhat.com> <20151013091456.GD4906@noname.str.redhat.com> From: John Snow Message-ID: <561D2865.3000309@redhat.com> Date: Tue, 13 Oct 2015 11:51:01 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Block device size rounding List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , Kevin Wolf Cc: Sai Pavan Boddu , "qemu-devel@nongnu.org Developers" , stefanha@redhat.com, Peter Crosthwaite On 10/13/2015 11:30 AM, Peter Crosthwaite wrote: > On Tue, Oct 13, 2015 at 2:14 AM, Kevin Wolf wrote: >> Am 12.10.2015 um 20:26 hat John Snow geschrieben: >>> >>> >>> On 10/12/2015 02:09 PM, Peter Crosthwaite wrote: >>>> On Mon, Oct 12, 2015 at 9:26 AM, Eric Blake wrote: >>>>> On 10/12/2015 09:56 AM, John Snow wrote: >>>>> >>>>>>> What is the correct action here though? If the file is writeable should >>>>>>> we just allow the device to extend its size? Is that possible already? >>>>>>> Just zero-pad read-only? >>>>>>> >>>>>> >>>>>> Read-only seems like an easy case of append zeroes. >>>>> >>>>> Yes, allowing read-only with append-zero behavior seems sane. >>>>> >>>>>> >>>>>> Read-write ... well, we can't write-protect just half of a 512k block. >>>>> >>>>>> Probably just forcibly increasing the size on RW or refusing to use the >>>>>> file altogether are probably the sane deterministic things we want. >>>>> >>>>> I'd lean towards outright rejection if the file size isn't up to snuff >>>>> for use as read-write. Forcibly increasing the size (done >>>>> unconditionally) still feels like magic, and may not be possible if the >>>>> size is due to something backed by a block device rather than a file. >> >> Agreed, let's just reject the image for r/w. Image resize should always >> been an explicit action invoked by the user, not a side effect of using >> the image with a specific device. >> >>>> Inability to extend is easily detectable and can become a failure mode >>>> in it's own right. If we cant extend the file perhaps we can just >>>> LOG_UNIMP the data writes? Having to include in your user instructions >>>> "dd your already-on-SATA file system to this container just so it can >>>> work for SD" is a pain. >>>> >>>> Regards, >>>> Peter >>>> >>> >>> Fits within my "Always extend the size" answer. Failing to do so is a >>> good cause to fail. >>> >>> I'm not sure if this is the sort of thing that might require an extra >>> flag or option for compatibility reasons or not, though. If there is no >>> precedent for QEMU resizing a block device to make it compatible with a >>> particular device model, it's probably reasonable that no management >>> tool is expecting this to happen automatically either. >>> >>> Then again, it's still annoying that the current default is definitely >>> broken. >> >> That's not so clear to me. Strictly speaking, this is really a user >> error because the user passed an image that isn't suitable for the >> device. All we're discussing is handling this user error friendlier. >> >> Maybe we should take a step back: What's the specific use case here, >> i.e. where does the misaligned image come from and what is it used for? > > An ext filesystem image built by the Yocto build system. It is passed > straight to QEMU as a raw image. The user does not create disk images, > they are done by the build system. Note that the build system is not > QEMU specific, it is designed to target either QEMU or be used for > some form of real-hardware deployment so padding there is > inappropriate. > >> I assume this is not an image created with qemu-img, because then the > > I am not using qemu-img at all. > >> obvious options would already result in an aligned size. >> > > Maybe. What is the alignment of qemu-img? Note this requires 512K > alignment, which is kinda huge. > >>> I think this is going to boil down into an interface-and-expectations >>> argument. I am otherwise in favor of just forcing the resize whenever >>> possible and failing when it isn't. >> >> I'm strongly objecting to any automagic resizing of images. >> > > Can we LOG_UNIMP writes to the missing sectors? The the user can RW to > the in-band sectors which should contain the limit of a pre-existing > filesystem. > This sounds potentially dangerous. Do we know for sure any data written here is unimportant? If it's all zeroes, we can probably guess it's unimportant. As soon as any non-zero data lands up in this extension range... how do we assert that this is garbage? I don't think we can... > Regards, > Peter > >> Kevin