>On Fri, 25 Sep 2009, James Lever wrote: >> >> NFS Version 3 introduces the concept of "safe asynchronous writes.? > >Being "safe" then requires a responsibilty level on the client which >is often not present. For example, if the server crashes, and then >the client crashes, how does the client resend the uncommitted data? >If the client had a non-volatile storage cache, then it would be able >to responsibly finish the writes that failed.
If the client crashes, it is clear that "work will be lost" up to the point that the client did a successful commit. Other than support for the NFSv3 commit operation and resending the missing operations. If the client crashes, we know that non-committed operations may be dropped in the floor. >The commentary says that normally the COMMIT operations occur during >close(2) or fsync(2) system call, or when encountering memory >pressure. If the problem is slow copying of many small files, this >COMMIT approach does not help very much since very little data is sent >per file and most time is spent creating directories and files. Indeed; the commit is mostly to make sure that the pipe between the server and the client can be filled for write operations. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
