On Fri, Mar 14, 2008 at 3:35 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > 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? There can't be writes lingering around after the close ... filp_close does a flush before calling fput. -- Thanks, Steve -- 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
