From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKFY9-00087c-OT for qemu-devel@nongnu.org; Mon, 04 Jul 2016 21:53:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKFY4-0003iJ-L1 for qemu-devel@nongnu.org; Mon, 04 Jul 2016 21:53:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKFY4-0003i9-Ct for qemu-devel@nongnu.org; Mon, 04 Jul 2016 21:53:16 -0400 References: <577A6955.6020603@kamp.de> From: Eric Blake Message-ID: <577B130A.3040205@redhat.com> Date: Mon, 4 Jul 2016 19:53:14 -0600 MIME-Version: 1.0 In-Reply-To: <577A6955.6020603@kamp.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vrM4xiHhUNX1xLTUQNCq8bcK9mFqkvKmt" 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) --vrM4xiHhUNX1xLTUQNCq8bcK9mFqkvKmt From: Eric Blake To: Peter Lieven , "qemu-devel@nongnu.org" Cc: Kevin Wolf Message-ID: <577B130A.3040205@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. A non-power-of-2 max_ws_len shouldn't be a problem, but opt_transfer_len and opt_discard_alignment not being a power of 2 impacts other code. 15MB is a rather odd page size. >=20 > I think we cannot assert that that these alignments are a power of 2. Perhaps that means we should just fix our code to round things down to the nearest power of 2 (8MB) for the opt_transfer_len and opt_discard_alignment values. Can you post a stack-trace of the actual assertion you are hitting? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --vrM4xiHhUNX1xLTUQNCq8bcK9mFqkvKmt 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/ iQEcBAEBCAAGBQJXexMKAAoJEKeha0olJ0Nq9/oH/jqdCUR/2XWl4O5F/s9HttpC 3RXAdRx9se4b4oz2iZWzOrGUeN24HRvU/cY1WpbM7mbT6yAOtRqZOXThwjzywDTm lj7qGwmjgTmulexz60ER+chTVqOVrbYMUqXNlFkckb5rzaucxVkHt2qiedGtwaya bvpL/8L3rprtQQIvKBUxQ/SDnqNjEXmIcw3mjr6J3rkpN6UzXPaS5QG5p4MQyxBy PdSpF58evjZjQbgCDS3UcM5osecYnwa1g0Ay173hXouFNsrgKfbLWTX4PlzVQ3HV ryWTmbXgzoUeUaLLY9YWz3Bm58nB0TUivf3i4C8b1g681Cc+D/Amyv8gc8kvLk0= =crPP -----END PGP SIGNATURE----- --vrM4xiHhUNX1xLTUQNCq8bcK9mFqkvKmt--