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@xxxxxxxxxxxxxxx. - Bryan > > Paul >
