On Fri, 14 Mar 2008 14:19:06 -0500 "Steve French" <smfrench@xxxxxxxxx> wrote: > On Fri, Mar 14, 2008 at 11:55 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Fri, 14 Mar 2008 11:16:41 -0500 > > > > "Steve French" <smfrench@xxxxxxxxx> wrote: > > > > > > > I don't worry about flushing atime (anyone crazy enough to do that > > > would pay a huge performance penalty). > > > Access is usually checked on open right ... so once a file is open > > > even if the file becomes read-only, the writes, even cached writes > > > continue. > > > > > > > Ahh, you're correct. I've been doing a lot of NFS work lately and was > > thinking stateless... :-) > > > > That patch should be OK then, though I think if someone is purposefully > > setting the atime we should take care not to clobber it. We're not > > going to be going through this codepath on every atime update, are we? > > Just on utimes() type calls, correct? If so, doing a flush on atime > > updates might be reasonable as well... > > > > Jeff Layton <jlayton@xxxxxxxxxx> > > > > I don't think we need to flush before setting (just) atime. > If the problem with timestamps is delayed writes getting written out > on close ... won't close update the atime anyway? > > Consider that an app like tar might do something like this: open() write() write() write() close() utimes() The app would likely set the mtime too, but I'm not sure we should make that assumption. The question is -- should we allow that utimes() call to be clobbered by writes lingering around after the close() returns? IMO, we shouldn't. The situation in this case is really the same for atime and mtime. Both would be clobbered by a delayed write, so we should really treat them the same... -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
