From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axVC3-0005C8-DI for qemu-devel@nongnu.org; Tue, 03 May 2016 03:56:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axVBr-0007vj-M8 for qemu-devel@nongnu.org; Tue, 03 May 2016 03:56:25 -0400 Date: Tue, 3 May 2016 09:55:35 +0200 From: Kevin Wolf Message-ID: <20160503075535.GB3917@noname.str.redhat.com> References: <1462052936-16933-1-git-send-email-eblake@redhat.com> <20160502153529.GE4882@noname.redhat.com> <57277583.1030209@redhat.com> <57278B08.3080909@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: <57278B08.3080909@redhat.com> 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: Eric Blake Cc: Fam Zheng , "open list:Block I/O path" , qemu-stable@nongnu.org, qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , Paolo Bonzini --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 02.05.2016 um 19:14 hat Eric Blake geschrieben: > On 05/02/2016 09:42 AM, Eric Blake wrote: > > On 05/02/2016 09:35 AM, Kevin Wolf wrote: > >> Am 30.04.2016 um 23:48 hat Eric Blake geschrieben: > >>> NBD has situations where it can support FUA but not ZERO_WRITE; > >>> when that happens, the generic block layer fallback was losing > >>> the FUA flag. The problem of losing flags unrelated to > >>> ZERO_WRITE has been latent in bdrv_co_do_write_zeroes() since > >>> aa7bfbff, but back then, it did not matter because there was no > >>> FUA flag. But ever since 93f5e6d8 added bdrv_co_writev_flags(), > >>> the loss of flags can impact correctness. > >>> > >=20 >=20 > >> then we still don't get the necessary flush unless the driver's > >> .bdrv_co_write_zeroes() implementation explicitly handles FUA. As far = as > >> I know, we don't have any driver that implements FUA there. > >=20 > > NBD will, once we get to that part of my series. >=20 > 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_zeroes > request. Hm, not sure if it makes sense, but let me write that thought down: 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 and in this case the iscsi driver would return only BDRV_REQ_ZERO_WRITE. If we ever decided to get rid of .bdrv_co_write_zeroes() and instead use =2Ebdrv_co_pwritev() with BDRV_REQ_ZERO_WRITE, this would probably be the most consistent interface. Kevin --9zSXsLTf0vkW971A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXKFl3AAoJEH8JsnLIjy/WM8QP/2QoTZ/ihTUAR1Yv1wXCQTti GJhz8RT4OIFHMDBI5v2l3xFgBgtN053lDnUGg/4vHmDhwDdx3LLEZCskHuRTXXvI 6ueBI8kPSw+UTgkscj50esf1rzZUV060JMP7RG6fCPDMeAweod0gmgsmzzCiEMDM u8yEbd0GMgVWa8NKqqC7HPTYCcB+4wQYxJUAowCKFzF868age2nIAtM+Fak3f3Cc Xg8ymGDKOVfI65wqejEknrwb5RZbpL4bgA8hRajGk59Wn4H3eyg3mCKZ+CiS98XI JN5EYRheTGA/3SiCstP8jVQM9erBdn+PUOY1aL0l84tk76kFc1ivSY31/mYu4AfG tbGimOIXxZ/PZ04Jd/ldtEecvGBFeMqDs73D+aQ47PuYINy5yoL8eBpSqFTwBWm3 Sckilr6ktRRhZqyI96enSt1yvq+5tbm+mdx/QJ19ncPQ+NgFD//sAIt45QfHwn26 j2Am/FZJro8UmhhvQqD113Jq65JpnAIcoVYaS3Ub9tg/ZQXcRDMHsBNWf66NGVXF fc22Ww03Y43ZxRCf21oIx13m0QmDWmFyEU9P3JtWH9xLID6aSc+JwwgYUqb2L08k rYMQVPM1XwB1oYSCZDY5sIomzcdrfwMcjRIGSpbWnRKWEG/mEVM1qS+CeN1i8iPB pf5O3asOKncjUpPV4Grb =+sSj -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A--