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