On Wed, Dec 12, 2012 at 9:34 AM, Paul Gideon Dann <pdgiddie@gmail.com>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
On Wednesday 12 Dec 2012 08:58:52 you wrote: 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