[PATCH v3 5/5] doc: Reflow paragraphs after recent edits
Not strictly necessary, but makes it easier to read the original
markup rather than having to refer to the rendered webpage. No
content change.
Signed-off-by: Eric Blake <eblake@redhat.com>
---
doc/proto.md | 34 ++++++++++++++++++----------------
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/doc/proto.md b/doc/proto.md
index b5f21e3..5f678b3 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -739,17 +739,18 @@ information request, it MUST abide by the block size constraints it
receives. Clients MAY issue `NBD_OPT_INFO` with `NBD_INFO_BLOCK_SIZE` to
learn the server's constraints without committing to them.
-If block size constraints have not been advertised or agreed on externally,
-then a server SHOULD support a default minimum block size of 1, a preferred
-block size of 2^12 (4,096), and a maximum block size that is effectively unlimited (0xffffffff, or the export size if that
+If block size constraints have not been advertised or agreed on
+externally, then a server SHOULD support a default minimum block size
+of 1, a preferred block size of 2^12 (4,096), and a maximum block size
+that is effectively unlimited (0xffffffff, or the export size if that
is smaller), while a client desiring maximum interoperability SHOULD
constrain its requests to a minimum block size of 2^9 (512), and limit
`NBD_CMD_READ` and `NBD_CMD_WRITE` commands to a maximum block size of
-2^25 (33,554,432). A server that
-wants to enforce block sizes other than the defaults specified here
-MAY refuse to go into transmission phase with a client that uses
-`NBD_OPT_EXPORT_NAME` (via a hard disconnect) or which uses
-`NBD_OPT_GO` without requesting `NBD_INFO_BLOCK_SIZE` (via an error reply of
+2^25 (33,554,432). A server that wants to enforce block sizes other
+than the defaults specified here MAY refuse to go into transmission
+phase with a client that uses `NBD_OPT_EXPORT_NAME` (via a hard
+disconnect) or which uses `NBD_OPT_GO` without requesting
+`NBD_INFO_BLOCK_SIZE` (via an error reply of
`NBD_REP_ERR_BLOCK_SIZE_REQD`); but servers SHOULD NOT refuse clients
that do not request sizing information when the server supports
default sizing or where sizing constraints can be agreed on
@@ -759,10 +760,10 @@ defaults MUST cleanly error commands that fall outside the constraints
without corrupting data; even so, enforcing constraints in this manner
may limit interoperability.
-A client MAY choose to operate as if tighter block size constraints had
-been specified (for example, even when the server advertises the default
-minimum block size of 1, a client may safely use a minimum block size
-of 2^9 (512)).
+A client MAY choose to operate as if tighter block size constraints
+had been specified (for example, even when the server advertises the
+default minimum block size of 1, a client may safely use a minimum
+block size of 2^9 (512)).
The minimum block size represents the smallest addressable length and
alignment within the export, although writing to an area that small
@@ -792,10 +793,11 @@ something other than a power of 2, but MUST be either an integer
multiple of the minimum block size or the value 0xffffffff for no
inherent limit, MUST be at least as large as the smaller of the
preferred block size or export size, and SHOULD be at least 2^20
-(1,048,576) if the export is that large. For convenience, the server MAY advertise a
-maximum block size that is larger than the export size, although in
-that case, the client MUST treat the export size as the effective
-maximum block size (as further constrained by a nonzero offset).
+(1,048,576) if the export is that large. For convenience, the server
+MAY advertise a maximum block size that is larger than the export
+size, although in that case, the client MUST treat the export size as
+the effective maximum block size (as further constrained by a nonzero
+offset).
The server MAY support individual commands that support a larger
length than the stated maximum block length (such as `NBD_CMD_TRIM`
--
2.14.3
Reply to: