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 <ebl...@redhat.com> 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? I assume this is not an image created with qemu-img, because then the obvious options would already result in an aligned size. > 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. Kevin
