From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQ11N-00006k-7a for qemu-devel@nongnu.org; Wed, 20 Jul 2016 19:35:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQ11K-00025H-4J for qemu-devel@nongnu.org; Wed, 20 Jul 2016 19:35:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQ11J-00024n-SA for qemu-devel@nongnu.org; Wed, 20 Jul 2016 19:35:18 -0400 References: <577A6955.6020603@kamp.de> From: Eric Blake Message-ID: <57900AB3.3040705@redhat.com> Date: Wed, 20 Jul 2016 17:35:15 -0600 MIME-Version: 1.0 In-Reply-To: <577A6955.6020603@kamp.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a0xn44VQ0jbtLUh22NwCqvUpgCowLuNBx" Subject: Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , "qemu-devel@nongnu.org" Cc: Kevin Wolf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a0xn44VQ0jbtLUh22NwCqvUpgCowLuNBx From: Eric Blake To: Peter Lieven , "qemu-devel@nongnu.org" Cc: Kevin Wolf Message-ID: <57900AB3.3040705@redhat.com> Subject: Re: Regression: block: Add .bdrv_co_pwrite_zeroes() References: <577A6955.6020603@kamp.de> In-Reply-To: <577A6955.6020603@kamp.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/04/2016 07:49 AM, Peter Lieven wrote: > Hi, >=20 > the above commit: >=20 > commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323 > Author: Eric Blake > Date: Wed Jun 1 15:10:03 2016 -0600 >=20 > block: Add .bdrv_co_pwrite_zeroes() >=20 > introduces a regression (at least for me). >=20 > The Limits from the iSCSI Block Limits VPD have no requirement of being= > a power of two. > We use Dell Equallogic iSCSI SANs for instance. They have an internal > page size of 15MB. And > they advertise this page size as max_ws_len, opt_transfer_len and > opt_discard_alignment. Since I don't have access to this device, let me double check: if you put a breakpoint in iscsi.c:iscsi_refresh_limits(), can you dump the contents of the struct iscsilun->bl? What is the block size of this device (512, 4096, something else)? Also, while the device is advertising that the optimal discard alignment is 15M, that does not tell me the minimum granularity that it can actually discard. Can you determine that value? That is, if I try to discard only 1M, does that actually result in a 1M allocation hole, or is it ignored? It sounds like qemu should be tracking 2 separate values: the minimum discard granularity (I suspect this number is a power of 2, at least the block size, and perhaps precisely equal to the block size), and the maximum discard granularity that results in the fewest/fastest discard of the entire device (not necessarily a power of 2). Or, maybe that merely means that qemu's pdiscard_alignment should be the MINIMUM granularity, and NOT the non-power-of-2 iscsilun->bl.opt_unmap_gran. Or put another way, I get that I can't discard more than 15M at a time. But I highly suspect that I do not have to align my discard requests to 15M boundaries. That is, if the discard granularity is 1M, then in qemu-io, 'discard 1M 15M' should result in a 15M hole, and should be no different from the result of 'discard 1M 14M; discard 15M 1M'. But if qemu sticks to pdiscard_alignment =3D=3D iscsilun->bl.opt_unmap_gran of 1= 5M, then both operations mistakenly discard nothing (because it is not aligned to a 15M boundary). >=20 > I think we cannot assert that that these alignments are a power of 2. Optimal size not being a power of 2 is not a problem, but I still suspect MINIMUM alignment is a power of 2, and I need to know how much head and tail to discard in the new byte-based discard routines in order to align requests up to the minimal discard alignment boundaries. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --a0xn44VQ0jbtLUh22NwCqvUpgCowLuNBx 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/ iQEcBAEBCAAGBQJXkAqzAAoJEKeha0olJ0NqUVwIAJTYwFGv3yN41ZDNX/5w0PyB KJ+OvubZhoxVNjOppwQFA0/CoYypem6IVmJ84S3NgslfuEAjF6QJo8zqw25tKqh3 NGAsBIYdfyrH2RPH6GzKDSeDVhgAaEkjmcoWbORPZvMT/h3gQ0EtuuvVTFCDGhq/ tPe3Ba2b5kKVLikz79Yd4EGz0gG4Nt7ULJBrLfnhGQEfSIHRstoEOog3g+D3BCkQ 3NyUk1GS4U6PRiO0lFhAxNVQuS4kQLC+FpT9XqvI8ifHMUkyrpOmRpInHYyK8xAe BxI6a2Z18bG8qfK5KIMoe0zfnSBGKWep+GGsUs2X/11OBR4cAzvqU8WyQxS5WMM= =oSZu -----END PGP SIGNATURE----- --a0xn44VQ0jbtLUh22NwCqvUpgCowLuNBx--