>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 >completeness.
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. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
