From nobody Tue Feb 10 08:27:58 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1520963019613537.1636366635097; Tue, 13 Mar 2018 10:43:39 -0700 (PDT) Received: from localhost ([::1]:41572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evnxa-0007tD-RT for importer@patchew.org; Tue, 13 Mar 2018 13:43:38 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1evnUr-0007K9-2B for qemu-devel@nongnu.org; Tue, 13 Mar 2018 13:14:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1evnUp-0000ru-BX for qemu-devel@nongnu.org; Tue, 13 Mar 2018 13:13:57 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39236 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1evnUm-0000oJ-B7; Tue, 13 Mar 2018 13:13:52 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E537A40201A8; Tue, 13 Mar 2018 17:13:51 +0000 (UTC) Received: from red.redhat.com (ovpn-121-135.rdu2.redhat.com [10.10.121.135]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8DA252026DFD; Tue, 13 Mar 2018 17:13:51 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Tue, 13 Mar 2018 12:13:35 -0500 Message-Id: <20180313171345.659672-8-eblake@redhat.com> In-Reply-To: <20180313171345.659672-1-eblake@redhat.com> References: <20180313171345.659672-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 13 Mar 2018 17:13:51 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 13 Mar 2018 17:13:51 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eblake@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 07/17] nbd/server: Honor FUA request on NBD_CMD_TRIM X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , "open list:Network Block Dev..." Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The NBD spec states that since trim requests can affect disk contents, then they should allow for FUA semantics just like writes for ensuring the disk has settled before returning. As bdrv_[co_]pdiscard() does not support a flags argument, we can't pass FUA down the block layer stack, and must therefore emulate it with a flush at the NBD layer. Note that in all reality, generic well-behaved clients will never send TRIM+FUA (in fact, qemu as a client never does, and we have no intention to plumb flags into bdrv_pdiscard). This is because the NBD protocol states that it is unspecified to READ a trimmed area (you might read stale data, all zeroes, or even random unrelated data) without first rewriting it, and even the experimental BLOCK_STATUS extension states that TRIM need not affect reported status. Thus, in the general case, a client cannot tell the difference between an arbitrary server that ignores TRIM, a server that had a power outage without flushing to disk, and a server that actually affected the disk before returning; so waiting for the trim actions to flush to disk makes little sense. However, for a specific client and server pair, where the client knows the server treats TRIM'd areas as guaranteed reads-zero, waiting for a flush makes sense, hence why the protocol documents that FUA is valid on trim. So, even though the NBD protocol doesn't have a way for the server to advertise what effects (if any) TRIM will actually have, and thus any client that relies on specific effects is probably in error, we can at least support a client that requests TRIM+FUA. Signed-off-by: Eric Blake Message-Id: <20180307225732.155835-1-eblake@redhat.com> --- nbd/server.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/nbd/server.c b/nbd/server.c index 83f21c55912..4776009a2d1 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -1638,6 +1638,9 @@ static coroutine_fn int nbd_handle_request(NBDClient = *client, case NBD_CMD_TRIM: ret =3D blk_co_pdiscard(exp->blk, request->from + exp->dev_offset, request->len); + if (ret =3D=3D 0 && request->flags & NBD_CMD_FLAG_FUA) { + ret =3D blk_co_flush(exp->blk); + } return nbd_send_generic_reply(client, request->handle, ret, "discard failed", errp); --=20 2.14.3