Date: Wed, 9 Nov 2011 11:09:28 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? Message-ID: <364937844.1458624.1320854968216.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <j9e26l$ht8$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras wrote: [good stuff snipped for brevity] > > This seems too extreme... doesn't NFSv4 have its own fsync()-like RPC > that does that manually? If it does, then I don't think there are any > differences between doing a write() on a local file system with e.g. > soft-updates enabled and doing a write on a NFS file system - in both > cases, no data is even remotely guaranteed to survive a crash unless a > fsync (or equivalent operation) was issued. > I think you have to be a bit careful when an assumption about loss of data after a crash is applied to a file server. If a client crashes, everyone pretty much assumes that recently written data might have been lost (in a Unix-like world, at least) and the crash is visible to users. However, take the following scenario: - User on desktop client edits a document for an hour, then saves it. --> NFS server crashes/reboots just after the "save". - User on desktop client goes off reading email for an hour, using a mail system not affected by the NFS server crash/reboot. - User goes back to document and finds an old damaged document file. --> User is very upset... My point is that a user on a client may not even realize the server crashed/rebooted. The above case can happen if async!=0, but not if async==0. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?364937844.1458624.1320854968216.JavaMail.root>