[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Block device size rounding
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC] Block device size rounding |
Date: |
Tue, 13 Oct 2015 11:14:56 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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 <address@hidden> 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
- [Qemu-devel] [RFC] Block device size rounding, Peter Crosthwaite, 2015/10/09
- Re: [Qemu-devel] [RFC] Block device size rounding, John Snow, 2015/10/12
- Re: [Qemu-devel] [RFC] Block device size rounding, Eric Blake, 2015/10/12
- Re: [Qemu-devel] [RFC] Block device size rounding, Peter Crosthwaite, 2015/10/15
- Re: [Qemu-devel] [RFC] Block device size rounding, John Snow, 2015/10/12
- Re: [Qemu-devel] [RFC] Block device size rounding, Markus Armbruster, 2015/10/13
- Re: [Qemu-devel] [RFC] Block device size rounding,
Kevin Wolf <=
- Re: [Qemu-devel] [RFC] Block device size rounding, Peter Crosthwaite, 2015/10/13
- Re: [Qemu-devel] [RFC] Block device size rounding, John Snow, 2015/10/15
- Re: [Qemu-devel] [RFC] Block device size rounding, Kevin Wolf, 2015/10/14
- Re: [Qemu-devel] [RFC] Block device size rounding, John Snow, 2015/10/16
- Re: [Qemu-devel] [RFC] Block device size rounding, Peter Crosthwaite, 2015/10/16