- If a storage client can rely on a server being of version v1.8.3 or
- later, it can extend the file efficiently by writing a single zero
- byte just before the new end-of-file. Otherwise it must explicitly
- write zeroes to all bytes between the old and new end-of-file. In any
- case it should avoid sending new_length larger than the size of the
- data after applying all write vectors.
+ If a storage client knows that the server supports zero-filling, for
+ example from the 'fills-holes-with-zero-bytes' key in its version
+ information, it can extend the file efficiently by writing a single
+ zero byte just before the new end-of-file. Otherwise it must
+ explicitly write zeroes to all bytes between the old and new
+ end-of-file. In any case it should avoid sending new_length larger
+ than the size of the data after applying all write vectors.