From patchwork Mon Apr 4 14:15:14 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 8741411 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id A54F19F36E for ; Mon, 4 Apr 2016 14:16:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E3FD820263 for ; Mon, 4 Apr 2016 14:16:35 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1FC712025A for ; Mon, 4 Apr 2016 14:16:35 +0000 (UTC) Received: from localhost ([::1]:58900 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an5Iw-0003ZE-Gs for patchwork-qemu-devel@patchwork.kernel.org; Mon, 04 Apr 2016 10:16:34 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an5In-0003Yx-Ft for qemu-devel@nongnu.org; Mon, 04 Apr 2016 10:16:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1an5Ii-0006s8-Fv for qemu-devel@nongnu.org; Mon, 04 Apr 2016 10:16:25 -0400 Received: from resqmta-po-01v.sys.comcast.net ([96.114.154.160]:49492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1an5Ii-0006s3-AG for qemu-devel@nongnu.org; Mon, 04 Apr 2016 10:16:20 -0400 Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by comcast with SMTP id n5GtaKiPFWmABn5Hjaj4av; Mon, 04 Apr 2016 14:15:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459779319; bh=tMJdan5iMT4dJOvT3wJeP3ERVsrG1rNWTy4iJnaSOYI=; h=Received:Received:From:To:Subject:Date:Message-Id; b=gCZ5XlkVDfvUsv/bC9/VaCO2C3l/QR2HQD0cFdNVNEMmOa+9CBOBT4pZy7Uk8ycca DFZtsXrXz3jLkjWu87+SOb+scpIXbOrSptGKcR3GJ38aYPcuQqCk1aw3vBQpoEhw3R PLs+PJV1N33WILwyv8pac02MIXu5bWzUIFzmRU5NpQzEMf/SwW8QHetxp1/OC+mmru Vnn0HXSywX4VWxwX5iWGwlS5WFG6NKATTJQM1zMWQd42gd9HNIN0ucc/4kKeBJz3Vh zy+2xQB+jUINgM2NPP+Ajs3oMf85PJUEkt6ZOojx3ZbPTNm7CzqpIjpsY2YPRQCOv7 Mc9NOEKOMNPSA== Received: from red.redhat.com ([24.10.254.122]) by resomta-po-07v.sys.comcast.net with comcast id eEFE1s00T2fD5rL01EFJUJ; Mon, 04 Apr 2016 14:15:19 +0000 From: Eric Blake To: nbd-general@lists.sourceforge.net Date: Mon, 4 Apr 2016 08:15:14 -0600 Message-Id: <1459779314-12266-1-git-send-email-eblake@redhat.com> X-Mailer: git-send-email 2.5.5 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.114.154.160 Cc: den@openvz.org, qemu-devel@nongnu.org, alex@alex.org.uk, pborzenkov@virtuozzo.com Subject: [Qemu-devel] [PATCH] doc: Allow NBD_CMD_FLAG_NO_HOLE during NBD_CMD_WRITE X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP qemu already has an existing server implementation option that will explicitly search the payload of NBD_CMD_WRITE for large blocks of zeroes, and punch holes in the underlying file. For old clients that don't know how to use the new NBD_CMD_WRITE_ZEROES, this is a workaround to keep the server's destination file approximately as sparse as the client's source. However, for new clients that know how to explicitly request holes, it is unnecessary overhead; and can lead to the server punching a hole and risking fragmentation or future ENOSPC even when the client explicitly wanted to write zeroes rather than a hole. So it makes sense to let the new NBD_CMD_FLAG_NO_HOLE work for WRITE as well as WRITE_ZEROES. Signed-off-by: Eric Blake Reviewed-by: Alex Bligh --- doc/proto.md | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/doc/proto.md b/doc/proto.md index 35a3266..fb97217 100644 --- a/doc/proto.md +++ b/doc/proto.md @@ -737,8 +737,14 @@ by a sparse file. With current NBD command set, the client has to issue through the wire. The server has to write the data onto disk, effectively losing the sparseness. -To remedy this, a `WRITE_ZEROES` extension is envisioned. This extension adds -one new command and one new command flag. +To remedy this, a `WRITE_ZEROES` extension is envisioned. This +extension adds one new transmission flag, one new command, and one new +command flag; and refines an existing command. + +* `NBD_FLAG_SEND_WRITE_ZEROES` + + The server SHOULD set this transmission flag to 1 if the + `NBD_CMD_WRITE_ZEROES` request is supported. * `NBD_CMD_WRITE_ZEROES` @@ -772,12 +778,27 @@ The server SHOULD return `ENOSPC` if it receives a write zeroes request including one or more sectors beyond the size of the device. It SHOULD return `EPERM` if it receives a write zeroes request on a read-only export. +* `NBD_CMD_WRITE` + + By default, the server MAY search for large contiguous blocks of + all zero content, and use trimming to zero out those portions of + the write, even if it did not advertise `NBD_FLAG_SEND_TRIM`; but + it MUST ensure that any trimmed areas of data read back as zero. + However, the client MAY set the command flag + `NBD_CMD_FLAG_NO_HOLE` to inform the server that the entire + written area MUST be fully provisioned, ensuring that future + writes to the same area will not cause fragmentation or cause + failure due to insufficient space. Clients SHOULD NOT set this + flag unless the server advertised `NBD_FLAG_SEND_WRITE_ZEROES` in + the transmisison flags. + The extension adds the following new command flag: -- `NBD_CMD_FLAG_NO_HOLE`; valid during `NBD_CMD_WRITE_ZEROES`. - SHOULD be set to 1 if the client wants to ensure that the server does - not create a hole. The client MAY send `NBD_CMD_FLAG_NO_HOLE` even - if `NBD_FLAG_SEND_TRIM` was not set in the transmission flags field. +- `NBD_CMD_FLAG_NO_HOLE`; valid during `NBD_CMD_WRITE` and + `NBD_CMD_WRITE_ZEROES`. SHOULD be set to 1 if the client wants to + ensure that the server does not create a hole. The client MAY send + `NBD_CMD_FLAG_NO_HOLE` even if `NBD_FLAG_SEND_TRIM` was not set in + the transmission flags field. ### `STRUCTURED_REPLY` extension