[arch-general] NFS close-to-open

[Bryan Schumaker]

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[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.

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.

- Bryan
> 
> Paul
>