[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH v3 1/5] doc: Mention FUA flag in more places



28.03.2018 22:43, Eric Blake wrote:
The spec is already clear that when the NBD_CMD_FLAG_FUA is in
use, commands that impact the disk don't reply until the action
has landed in permanent storage.  But this information is in a
different section, and someone reading about just the commands
may miss the connection between the flag documentation and the
commands that the flag can affect.  Add wording to NBD_CMD_WRITE
and NBD_CMD_WRITE_ZEROES to fix that.

Although NBD_CMD_TRIM also supports the FUA flag (for specific
implementations where the client knows via external means that
the server will guarantee a reads-as-zero after the trim
completes), the wording under NBD_CMD_TRIM didn't mention timing
to permanent storage, and in general TRIM+FUA makes less sense
between arbitrary client and server (the general definition of
TRIM states that you can't reliably read that area without a
subsequent write, as the read might see zeroes, stale data, or
even unrelated date, so waiting for something you can't read to
land on disk makes no sense).  So that command did not need
the same treatment in this patch.

Signed-off-by: Eric Blake <eblake@redhat.com>

looks unchanged since v2:

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

---
  doc/proto.md | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/proto.md b/doc/proto.md
index c7803e0..adf2651 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -1584,7 +1584,7 @@ The following request types exist:

      The server MUST write the data to disk, and then send the reply
      message. The server MAY send the reply message before the data has
-    reached permanent storage.
+    reached permanent storage, unless `NBD_CMD_FLAG_FUA` is in use.

      If an error occurs, the server MUST set the appropriate error code
      in the error field.
@@ -1641,7 +1641,7 @@ The following request types exist:

      The server MUST zero out the data on disk, and then send the reply
      message. The server MAY send the reply message before the data has
-    reached permanent storage.
+    reached permanent storage, unless `NBD_CMD_FLAG_FUA` is in use.

      A client MUST NOT send a write zeroes request unless
      `NBD_FLAG_SEND_WRITE_ZEROES` was set in the transmission flags field.


--
Best regards,
Vladimir


Reply to: