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 data, 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>