On Wed, Dec 12, 2012 at 9:34 AM, Paul Gideon Dann <pdgiddie@xxxxxxxxx>wrote: > On Wednesday 12 Dec 2012 08:58:52 you wrote: > > On 12/12/2012 05:35 AM, Paul Gideon Dann wrote: > > > On Tuesday 11 Dec 2012 12:08:46 you wrote: > > >> After more poking-about: filp_close() in the VFS calls > nfs_file_flush(), > > >> which writes the file back to the server. The struct file we're > given is > > >> freed up shortly after calling flush, so this looks like the last > chance > > >> we > > >> get to write changes (and I don't think we should change that). > > > > > > Hmm, so is this maybe an implementation limitation? I would expect > > > "nocto" to prevent that flushing, since that seems to be the main > purpose > > > of "nocto". But maybe it would have been too much work to buffer the > > > flushes, and so every file gets flushed on close anyway? > > > > > > Paul > > > > Something like that, yeah. "nocto" just applies to the attribute cache, > and > > does not change the flushing behavior. > > That's a pity. In that case, it seems the man page is a little > misleading, as > it at least implies (in the "Data and Metadata Coherence" section) that > "nocto" will disable the flushing. Also, at least some other > implementations > definitely do disable the flushing[1][2]. > > Do you know if this is a feature that can be requested? Since writes are > buffered already (unless mounted "sync"), I can't imagine it could be too > difficult to suppress the flush and let the file be written when the next > buffer is sent? But then I guess it would have been implemented already > if it > were that easy. > 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). - Bryan > > Paul > > [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 >
