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. >> > > 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. 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. >> -- >> Eric Blake eblake redhat com +1-919-301-3266 >> Libvirt virtualization library http://libvirt.org >> -- —js
