On 12/14/2012 04:50 AM, Paul Gideon Dann wrote: > On Thursday 13 Dec 2012 15:53:32 Bryan wrote: >> I double checked with Trond and he agrees that we shouldn't defer the flush >> because that would cause us to hold the file open for longer than we really >> should (and it would make NFS sillyrenames more difficult, too). > > I thought that's why the "nocto" documentation (and general guidance) says > it's not safe to use this mount option for directories that are shared between > several clients? Right. > > My particular usecase is a remote-mounted /var, which is used only by a single > client. I'd like to avoid the flushing bottleneck, but would also like to > avoid the danger of the client and server being out of sync if the server > falls over and reboots. Am I misunderstanding the stated purpose of "nocto" > (preventing close-to-open)? It seemed to fit this scenario perfectly :( 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. 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). What are your other export and mount options for this mount? Maybe you have something else that can be tuned... - Bryan > > Paul > > P.S.: Sorry, I've realised that I've been accidentally replying directly to > Bryan instead of to the mailing list. >
