From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axZS2-0000T4-Vb for qemu-devel@nongnu.org; Tue, 03 May 2016 08:29:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axZRr-0007wO-9W for qemu-devel@nongnu.org; Tue, 03 May 2016 08:29:13 -0400 References: <1462052936-16933-1-git-send-email-eblake@redhat.com> <20160502153529.GE4882@noname.redhat.com> <57277583.1030209@redhat.com> <57278B08.3080909@redhat.com> <20160503075535.GB3917@noname.str.redhat.com> From: Eric Blake Message-ID: <5728995F.3040703@redhat.com> Date: Tue, 3 May 2016 06:28:15 -0600 MIME-Version: 1.0 In-Reply-To: <20160503075535.GB3917@noname.str.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hBr7JoSQqFmX7qUpbcN3C6705aM365D3M" Subject: Re: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , "open list:Block I/O path" , qemu-stable@nongnu.org, qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hBr7JoSQqFmX7qUpbcN3C6705aM365D3M Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/03/2016 01:55 AM, Kevin Wolf wrote: >> And looking further, it looks like SCSI does NOT support FUA during >> WRITESAME(10/16), only during WRITE(10/16). Which means we probably >> want to start having both .supported_write_flags AND >> .supported_write_zero flags, so that at least the iscsi driver can >> properly report that it does NOT natively support FUA on a write_zeroe= s >> request. >=20 > Hm, not sure if it makes sense, but let me write that thought down: >=20 > You're going to convert .supported_write_flags to a function anyway. > Instead of adding a second function, how about passing a set of flags > there and the function returns a subset that it can support? For write > zeroes with FUA you would pass in BDRV_REQ_ZERO_WRITE | BDRV_REQ_FUA an= d > in this case the iscsi driver would return only BDRV_REQ_ZERO_WRITE. >=20 > If we ever decided to get rid of .bdrv_co_write_zeroes() and instead us= e > .bdrv_co_pwritev() with BDRV_REQ_ZERO_WRITE, this would probably be the= > most consistent interface. I'm currently leaning towards two flags rather than a function (the flags are set during .bdrv_open(), and don't change during the life of the BDS): bs->supported_write_flags =3D BDRV_REQ_FUA; bs->supported_zero_flags =3D BDRV_REQ_MAY_UNMAP; // | BDRV_REQ_FUA and keeping the BDRV_REQ_ZERO_WRITE as a special case in the block layer that chooses between .bdrv_co_write_zeroes() or .bdrv_driver_pwrite(). MAY_UNMAP makes no sense on a normal write, just as iscsi doesn't allow FUA on a zero write, so having the two sets of valid flags according to operations, as well as the two driver entries, seems to make the most sense. Then io.c, we ignore MAY_UNMAP where it is unsupported, and emulate FUA on both write and write_zero as needed. Of course, if we ever have a driver that can support everything through a single entry, it could advertise supported_write_flags =3D BDRV_REQ_FUA= | BDRV_REQ_ZERO_WRITE | BDRV_REQ_MAY_UNMAP and provide only =2Ebdrv_driver_pwrite(), but I don't think that will be happening. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --hBr7JoSQqFmX7qUpbcN3C6705aM365D3M 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/ iQEcBAEBCAAGBQJXKJlgAAoJEKeha0olJ0NqIhwH/3lCQP4LK7U/NuIXLWKkDXJ/ bCtMwlo6tmlb9Bi9rI5WtpYC7envOEKVU2x1p+lKhwzLRT8iFHz2t3eV9YSfiqgY fBxizX1gB9L6pTbomgmcqakGPjYTwasFmwWz8qi8LP6TazWWT086f56YYhMZp1XG 6br77PSyWVmHOQO1JZhclGVQOvAhNyVlHwIpIlEWRBPEkDWlaJajCs3MeR7L0tT8 +XdXF9wCfZhqylMgYZJuE7XEdxwUp6X8nvcWAAe78hoGYJ34ZKPcTf9X1A9Ny4RM vCy1v0BoxR1+cavaftweYd2DX343XPXNQIj6fDfxXt0t8POCD7TGiaYxeQXvMGo= =R1Lq -----END PGP SIGNATURE----- --hBr7JoSQqFmX7qUpbcN3C6705aM365D3M--