[arch-general] NFS close-to-open

[Paul Gideon Dann]

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[1][2] 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.

[1] http://docs.oracle.com/cd/E19082-01/819-2240/mount-nfs-1m/index.html
[2] 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.

Paul