NFS reads vs. writes

[Bruce Evans]

On Mon, 4 Jan 2016, Mikhail T. wrote:

> On 03.01.2016 20:37, Rick Macklem wrote:
>> This issue isn't new. It showed up when Sun introduced NFS in 1985.
>> NFSv3 did change things a little, by allowing UNSTABLE writes.
> Thank you very much, Rick, for the detailed explanation.
>> If you use "sync=disabled"
>>       (I'm not a ZFS guy, but I think that is what the ZFS option looks likes) you
>>       *break* the NFS protocol (ie. violate the RFC) and put your data at some risk,
>>       but you will typically get better (often much better) write performance.
> Yes, indeed. Disabling sync got the writing throughput all the way up to
> about 86Mb/s... I still don't fully understand, why local writes are
> able to achieve this speed without async and without being considered
> dangerous.

86 Mbits/S is still slow.  Do you mean Mbytes/S?

Try fsync() to make the local writes slow too.

There is considerable confusiion between sync, async and neither.  "neither"
used to mean to writes using the bawrite() ("async" write) function.  "async"
means to write _not_ using bawrite(), but using the bdwrite() ("delayed"
write) function.  Soft updates obfuscate this more.  "neither" with them
means to write with more order than bawrite() and with less delay than
with bdwrite(), so that writes are more robust and also faster than with
simple bawrite().

"neither" writes are dangerous in ffs with soft updates only if the system
crashes so that the delayed writes are never done.  In zfs they are supposed
to be safe by writing the delayed writes to small fast storage.  I forget
what this is named.  This is supposed to work without any async hacks too.
Apparently it doesn't.  Maybe the nfs Commits are too large.

Bruce