Re: [Qemu-block] [PATCH for-2.8] block: Let write zeroes fallback work even with small max_transfer

[Kevin Wolf]

Am 10.11.2016 um 03:11 hat Fam Zheng geschrieben:
> On Wed, 11/09 14:06, Eric Blake wrote:
> > On 11/09/2016 07:49 AM, Stefan Hajnoczi wrote:
> > > On Tue, Nov 08, 2016 at 04:52:15PM -0600, Eric Blake wrote:
> > >> Commit 443668ca rewrote the write_zeroes logic to guarantee that
> > >> an unaligned request never crosses a cluster boundary.  But
> > >> in the rewrite, the new code assumed that at most one iteration
> > >> would be needed to get to an alignment boundary.
> > >>
> > >> However, it is easy to trigger an assertion failure: the Linux
> > >> kernel limits loopback devices to advertise a max_transfer of
> > >> only 64k.  Any operation that requires falling back to writes
> > >> rather than more efficient zeroing must obey max_transfer during
> > >> that fallback, which means an unaligned head may require multiple
> > >> iterations of the write fallbacks before reaching the aligned
> > >> boundaries, when layering a format with clusters larger than 64k
> > >> atop the protocol of file access to a loopback device.
> > >>
> > >> Test case:
> > >>
> > >> $ qemu-img create -f qcow2 -o cluster_size=1M file 10M
> > >> $ losetup /dev/loop2 /path/to/file
> > >> $ qemu-io -f qcow2 /dev/loop2
> > >> qemu-io> w 7m 1k
> > >> qemu-io> w -z 8003584 2093056
> > > 
> > > Please include a qemu-iotests test case to protect against regressions.
> > 
> > None of the existing qemu-iotests use losetup; I guess the closest thing
> > to do is crib from a test that uses passwordless sudo?
> > 
> > It will certainly be a separate commit, but I'll give it my best shot to
> > post something soon.
> 
> Alternatively, maybe add a blkdebug option to emulate a small max_transfer at
> the protocol layer?

This sounds like the better option indeed.

Kevin