On Fri, Joerg Schilling wrote: > Spencer Shepler <[EMAIL PROTECTED]> wrote: > > > I didn't comment on the error conditions that can occur during > > the writing of data upon close(). What you describe is the preferred > > method of obtaining any errors that occur during the writing of data. > > This occurs because the NFS client is writing asynchronously and the > > only method the application has of retrieving the error information > > is from the fsync() or close() call. At close(), it is to late > > to recovery so fsync() can be used to obtain any asynchronous error > > state. > > > > This doesn't change the fact that upon close() the NFS client will > > write data back to the server. This is done to meet the > > close-to-open semantics of NFS. > > Your working did not match with the reality, this is why I did write this. > You did write that upon close() the client will first do something similar to > fsync on that file. The problem is that this is done asynchronously and the > close() return value does noo contain an indication on whether the fsync > did succeed.
Sorry, the code in Solaris would behave as I described. Upon the application closing the file, modified data is written to the server. The client waits for completion of those writes. If there is an error, it is returned to the caller of close(). Spencer _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
