John Snow <js...@redhat.com> writes: > 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.
This is tolerable. Do we want to warn? A reopen can bring in the read/write case. >>>> 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. Concur. >> 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. Whenever QEMU proper can extend to the right size, qemu-img should be able to do so as well, shouldn't it? QEMU's error message could even explain how. > 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. I agree it's about expectations. When I give QEMU read/write access to an image, I expect it to modify the image, but I don't expect it to resize it on its own. Perhaps my expectation is wrong. Do we have precedence?
