[arch-general] NFS close-to-open
bjschuma at gmail.com
Mon Dec 17 14:35:45 EST 2012
On 12/17/2012 06:12 AM, Paul Gideon Dann wrote:
> On Friday 14 Dec 2012 11:09:59 you wrote:
>> I'm sorry, but I think you are misunderstanding the mount option. "nocto"
>> is used to cut down on getattrs when deciding if a file has changed, and
>> has nothing to do with when writes are sent to the server.
> That seems to be the case for the Linux NFS implementation, but not
> universally. My question really is whether it might be sensible to request
> that "nocto" be extended, so that flushing doesn't occur on close. Since
> other non-Linux implementations specifically do disable flushing when
> "nocto" is enabled, I'm wondering why Linux doesn't. Since "close-to-open"
> includes the flush-on-close behaviour, it seems intuitive to me that "nocto"
> should mean "no flush-on-close" too. With "cto" disabled, why does the file
> need to be flushed? There is no requirement to fulfil.
>  http://docs.oracle.com/cd/E19082-01/819-2240/mount-nfs-1m/index.html
>  http://www.solarisinternals.com/wiki/index.php/File_Systems
>> The "async"
>> mount option (enabled by default) already delays writes to the server under
>> normal usecases, but we still flush data when files are closed see "The
>> sync mount option" section in nfs(5).
> Since nfs-utils 1.0.0, "sync" has been the default option, because "async" is
> not really a safe option. "async" work fine, and improves performance a
> *lot*, but it does mean that the client thinks the data is committed to disk
> when in fact it isn't, which is potentially dangerous. If "nocto" would
> disable the whole close-to-open behaviour (including the flush-on-close), it
> would be possible for the client to recover from a server failure, because it
> would know exactly what hadn't yet been flushed, and the server wouldn't be
> lying to it about when data is actually safely on disk.
>> What are your other export and mount options for this mount? Maybe you have
>> something else that can be tuned...
> I'm using "async" now, and performance is fine. This is now more of a
> theoretical correctness question, to be honest. Really, I'd like to
> understand why the kernel developers chose not to disable flush-on-close when
> "nocto" is enabled. I suspect it was just to simplify the code, but I feel
> that disabling flush-on-close would be a more correct solution than "async"
> for single-client exports.
This code was written before I joined up, so at this point I can only make guesses about why it was implemented this way. I think I'm the only NFS developer using Arch, so you might get better information asking on linux-nfs at vger.kernel.org.
More information about the arch-general