>On Dec 9, 2006, at 8:59 , Jim Mauro wrote:
>> Anyway....I'm feeling rather naive' here, but I've seen the "NFS
>> enforced synchronous semantics" phrase
>> kicked around many times as the explanation for suboptimal
>> performance for metadata-intensive
>> operations when ZFS is the underlying file system, but I never
>> really understood what's "unsynchronous"
>> about doing the same thing to a local ZFS
>If I remember correctly, the difference is that NFS requires that the
>operation be committed to stable storage before the return to the
>client. This is definitely a heavier operation than the local case,
>where the return to the caller may happen as soon as the operation is
>cached. If there's a crash, the local system does not guarantee to
>the caller that the operation is on disk, but NFS does.
>Both guarantee consistency but NFS makes stronger guarantees of
The currenet way to solve this from the NFS server's perspective
is to call something equivalent to "sync()". It was my understanding
that disable ZIL would make such operations more or less "asynchronous"
but it still seems that NFS is doing a sync() like thing.
Perhaps there should be a different mechanism for making VOP_*
calls, calls which do not return until the specific call was
committed to stable storage. (Interested parties get notified
when such events happen).
Unfortunately, that would cause the NFS client system calls to sleep
until the calls are completed (as they do now), but there doesn't seem
to be a need for that; writes currently need a specific commit and
it would perhaps be worthwhile to investigate more asynchronous
behaviour. As long as the client remembers the non-committed calls,
there is no "data loss" issue; when the client crashes, you expect
data loss; when the server crashes, the client resends.
nfs-discuss mailing list