>Well being fair to Linux the default for NFS exports is to export them >'sync' now which syncs to disk on close or fsync. It has been many >years before they exported 'async' by default. Now if Linux admins set >their shares 'async' and loose important data then it's operator error >and not Linux's fault.
Is that what "sync" means in Linux? As NFS doesn't use "close" or "fsync", what exactly are the semantics. (For NFSv2/v3 each *operation* is sync and the client needs to make sure it can continue; for NFSv4, some operations are async and the client needs to use COMMIT) >If apps don't care about their data consistency and don't sync their >data I don't see why the file server has to care for them. I mean if >it were a local file system and the machine rebooted the data would be >lost too. Should we care more for data written remotely then locally? If the system crashes the applications is also gone but if the server reboots, data should *never* be lost; the sync may just miss the window. The application continuous to run so clearly we must handle this differently. What you're saying sounds like that the kernel can forget what you wrote because you didn't call fsync(). Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
