From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz28S-0001jK-Eo for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:51:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz28R-0006J5-EO for qemu-devel@nongnu.org; Tue, 25 Oct 2016 09:51:24 -0400 References: <8a8853e4-d1ce-66b2-5214-b508fb897386@redhat.com> <20161025083924.GB4695@noname.str.redhat.com> From: Eric Blake Message-ID: <28dabb20-ab80-95a3-f399-292afd52ecdf@redhat.com> Date: Tue, 25 Oct 2016 08:51:14 -0500 MIME-Version: 1.0 In-Reply-To: <20161025083924.GB4695@noname.str.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Itt0LAiNWO5hpoTaJwVsMsNxdm2lfXJSb" Subject: Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Ed Swierk Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, "Denis V. Lunev" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Itt0LAiNWO5hpoTaJwVsMsNxdm2lfXJSb From: Eric Blake To: Kevin Wolf , Ed Swierk Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, "Denis V. Lunev" Message-ID: <28dabb20-ab80-95a3-f399-292afd52ecdf@redhat.com> Subject: Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k References: <8a8853e4-d1ce-66b2-5214-b508fb897386@redhat.com> <20161025083924.GB4695@noname.str.redhat.com> In-Reply-To: <20161025083924.GB4695@noname.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/25/2016 03:39 AM, Kevin Wolf wrote: >> It appears loop devices (with or without dm-crypt/LUKS) report a >> 255-sector maximum per request via the BLKSECTGET ioctl, which qemu >> rounds down to 64k in raw_refresh_limits(). Cool - I can make a loop device, so now I should have enough info to reproduce locally. I wonder if we should continue rounding down to a power of 2 (128 sectors), or if we should try to utilize the full 255 sector limit. But that's an independent patch and bigger audit, more along the lines of what we did for the weird scsi device with 15M limits. >> However this maximum >> appears to be just a hint: bdrv_driver_pwritev() succeeds even with a >> 385024-byte buffer of zeroes. >=20 > I suppose what happens is that we get short writes, but the raw-posix > driver actually has the loop to deal with this, so eventually we return= > with the whole thing written. >=20 > Considering the presence of this loop, maybe we shouldn't set > bs->bl.max_transfer at all for raw-posix. Hm, except that for Linux AIO= > we might actually need it. bdrv_aligned_preadv() fragments before calling into bdrv_driver_preadv(), but our write-zeroes fallback code is calling directly into bdrv_driver_preadv() rather than going through bdrv_aligned_preadv(); and I don't think we want to change that. In other words, it sounds like bdrv_co_do_pwrite_zeroes() has to do the same fragmentation that bdrv_aligned_preadv() would be doing. Okay, I think I know where to go with the patch, and hope to have something posted later today. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Itt0LAiNWO5hpoTaJwVsMsNxdm2lfXJSb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYD2NSAAoJEKeha0olJ0Nq8aEH/iAX8RkKiOiaVZ4/A+A3313f MYjXhGBJ0CRiMWDWvO/5lZGPkmz4euyLmOYR/ok37MjY255Ex+H6JIfpnAEaRggy Ksb3FHEq6ttpXitZgTUl5iOoVIZeyZOP9YCpDP1oscTmuxFxlnHWfaSmBtpB6Q2c rU4+opP9/3c/LRjb0Ig3qJMrT1q/onIi36Bu1EnTK67nFFi7b1pN3YJzk/9BNIYV NL0mSzmnNlb+XteOzW8rnAfNtIBtXK93NBGGw2qT973PFi8gMwuJcBV4Ne5nwg2w cUELGl7m9daqwDzBZpliFAf8ghlo0IzZKJnvaeWBK+72WYl5KLxFbziwxWUsxFk= =P/nv -----END PGP SIGNATURE----- --Itt0LAiNWO5hpoTaJwVsMsNxdm2lfXJSb--