From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ap28C-0001JP-5v for qemu-devel@nongnu.org; Sat, 09 Apr 2016 19:17:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ap28B-0006to-90 for qemu-devel@nongnu.org; Sat, 09 Apr 2016 19:17:32 -0400 References: <1460153158-21612-1-git-send-email-eblake@redhat.com> <1460153158-21612-19-git-send-email-eblake@redhat.com> From: Eric Blake Message-ID: <57098D83.1080503@redhat.com> Date: Sat, 9 Apr 2016 17:17:23 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lQgnvbO6HkPFWgLfNbUJMrGQcbQkBm5aG" Subject: Re: [Qemu-devel] [RFC PATCH 18/18] nbd: Implement NBD_CMD_WRITE_ZEROES on client List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "qemu-devel@nongnu.org" , Kevin Wolf , Paolo Bonzini , "open list:Block layer core" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lQgnvbO6HkPFWgLfNbUJMrGQcbQkBm5aG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/09/2016 04:57 AM, Alex Bligh wrote: >=20 > On 8 Apr 2016, at 23:05, Eric Blake wrote: >=20 >> RFC because there is still discussion on the NBD list about >> adding an NBD_OPT_ to let the client suggest server defaults >> related to scanning for zeroes during NBD_CMD_WRITE, which may >> tweak this patch. >> >> Upstream NBD protocol recently added the ability to efficiently >> write zeroes without having to send the zeroes over the wire, >> along with a flag to control whether the client wants a hole. >> >> The generic block code takes care of falling back to the obvious >> write lots of zeroes if we return -ENOTSUP because the server >> does not have WRITE_ZEROES. >> >> + ret =3D nbd_client_co_write_zeroes(bs, sector_num, nb_sectors, &f= lags); >> + if (ret < 0) { >> + return ret; >> + } >> + >> + /* The flag wasn't sent to the server, so we need to emulate it w= ith an >> + * explicit flush */ >=20 > Surely you only need to do this is the flag wasn't sent to the server, > i.e. if !(client->nbdflags & NBD_FLAG_SEND_FUA) >=20 > If you've sent a FUA request, no need to flush the whole thing. >=20 > nbd_co_writev_flags seems to have the same issue, which is where I gues= s > you got that from. No, the code is correct. In both functions, the logic is that if the lower-level knows that the server respects FUA, then it clears the flag before returning (flags is passed by reference, not value). Then at this higher level, if FUA is still set, the server is too old, so we do a fallback flush to get the same semantics for the write in question, but at higher cost of a full flush. >=20 >> + if (flags & BDRV_REQ_FUA) { >> + ret =3D nbd_client_co_flush(bs); >> + } >> + It's also this higher level that knows how to fall back to NBD_CMD_WRITE if the lower-level returned -ENOTSUP because the server doesn't support WRITE_ZEROES. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --lQgnvbO6HkPFWgLfNbUJMrGQcbQkBm5aG 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/ iQEcBAEBCAAGBQJXCY2DAAoJEKeha0olJ0Nql1sH/1mo6BUKfrxi9Fzdm9rc/MfK Ff4NxFIt82pUqA04Wyb1kvjQDbqY61Vs4q4ziC1kCR6w9hwkOrSVtcHxSgigR+ei 2KX6gZ56hYDYc7mYlxhqAumcI+tdIO83pY4J3SriO1pZcXDWzLQfDU1fL0MaI1x+ /vDX5gGQdLwn0cAJGKNPGFBVn0ZTs+YmuZicyL34jgupgv6Tl0Lf/b913NlZDrzz 4RFTRDzzBNLABEPvghWDlUjQYPJRAD4DMHYDI7zU+UMDQzlSSDyXmOp/hqZPQhP3 efSRvnwy+pTPmNihR25Jq3F1bxJPdxhbbS6d7tEKGw+OTJkStVz5UF5t5Er7AMc= =fiVU -----END PGP SIGNATURE----- --lQgnvbO6HkPFWgLfNbUJMrGQcbQkBm5aG--