On 12/11/2012 10:19 AM, Bryan Schumaker wrote: > On 12/11/2012 09:55 AM, Paul Gideon Dann wrote: >> On Tuesday 11 Dec 2012 09:07:12 Bryan Schumaker wrote: >>> After thinking on this some more and going through the code again, I think >>> that the "nocto" only affects writing and fetching attributes for a file >>> (the man page mentions using a heuristic to determine if files have changed >>> on the server). I think the VFS is in charge of scheduling the flush, so >>> we don't know if it's being called for close(), fsync() or any other >>> reason. The nocto flag is checked around calls to >>> __nfs_revalidate_inode(), which is used to update information about a file. >> I really appreciate you taking the time to look into this, Bryan. So you say >> you think that with "nocto", it's the VFS layer that's causing the flush on >> close now? That seems strange to me, since that's not normal behaviour for >> any filesystem other than NFS. If it's the attributes that are being checked >> by the heuristic, this also doesn't seem to explain why the data itself is >> being flushed... >> >> Paul > No problem! NFS is my day job :). I say "I think" because I've never traced through the close path before, but the parts that I saw didn't seem to flush anything (I'll admit that I still have a lot to learn, so I could be wrong). I'm about to look again because your "That seems strange to me, since that's not normal behaviour" comment makes me think I missed something... > > Data being flushed would be the normal behavior of the client using close-to-open, since data is written back to the server on close. Data being flushed makes sense (at least to me) because it doesn't look like we're doing anything special for flush when nocto is set. > > - Bryan 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). - Bryan
