Re: [PATCH] block/file-posix: Optimize for macOS

[Akihiko Odaki]

2021年2月25日(木) 2:31 Kevin Wolf <kwolf@redhat.com>:
>
> Am 24.02.2021 um 17:27 hat Stefan Hajnoczi geschrieben:
> > On Fri, Feb 19, 2021 at 05:51:48PM +0900, Akihiko Odaki wrote:
> > > This commit introduces "punch hole" operation and optimizes transfer
> > > block size for macOS.
> > >
> > > This commit introduces two additional members,
> > > discard_granularity and opt_io to BlockSizes type in
> > > include/block/block.h. Also, the members of the type are now
> > > optional. Set -1 to discard_granularity and 0 to other members
> > > for the default values.
> >
> > I remember BlockSizes was added specifically for s390 DASD devices.
> > Normally QEMU does not automatically expose details of the underlying
> > hardware to the guest because it breaks live migration compatibility.
> >
> > If a VM is running on host A where the value happens to be 512 bytes and
> > is migrated to host B where the value happens to be 4KB then:
> >
> > 1. The value reported to the guest by the storage device will change
> >    unexpectedly and the guest software is probably not prepared for this
> >    to happen.
> >
> > 2. I/O requests that violate the constraint imposed by host B's value
> >    will suddenly start failing and the VM may no longer be operational.
> >
> > I think there was an argument that DASDs are passthrough devices and the
> > user always knows what they are doing, so we can ignore this problem for
> > DASDs.
> >
> > This reasoning does not apply to POSIX files on macOS hosts, so I think
> > we need to figure out what to do here. The easiest option is not to
> > merge this patch series, but if this feature is important to you then we
> > need to think about how to extend the block size probing to be live
> > migration friendly or to change the QEMU command-line to support this
> > use case without unexpected live migration breakage.
>
> Dave actually made a good point on IRC: Even if we change live migration
> so that it doesn't break when we move to a host where different defaults
> are autodetected (we could do this by including these values in the
> migration stream and letting that override what the user specific on the
> command line), it still means that the guest visible device would change
> after the next reboot.
>
> The same can happen without live migration, either by copying the image
> to a different host, or by changing the hardware of the host.
>
> I'm not sure how critical such changes are now, but I seem to remember
> that in the past, one big reason to avoid them was that Windows guests
> would require reactivation after a few changes.
>
> (Also adding Peter to CC as the libvirt representative who, I suspect,
> might not like the idea of autodetecting by default very much :-))
>
> Kevin

The "copy" concern perhaps also applies to the host device backend,
which already has some auto detections. When the physical backend
device fails, a user may create a live snapshot, "dd" it to another
disk, and resume with the new disk, which can have different block
sizes.

I wonder if it is worthwhile to have an option to disable any kind of
autodetection depending on the host, including those of the host
device backend and maybe of subsystems other than block devices.

Regards,
Akihiko Odaki