[linux-cifs-client] Re: set last write time = fsync ?

[Jeff Layton]

On Fri, 14 Mar 2008 16:38:27 -0500
"Steve French" <smfrench at gmail.com> wrote:

> On Fri, Mar 14, 2008 at 3:35 PM, Jeff Layton <jlayton at redhat.com> wrote:
> > On Fri, 14 Mar 2008 14:19:06 -0500
> >
> > "Steve French" <smfrench at gmail.com> wrote:
> >
> >  > On Fri, Mar 14, 2008 at 11:55 AM, Jeff Layton <jlayton at redhat.com> wrote:
> >  > > On Fri, 14 Mar 2008 11:16:41 -0500
> >  > >
> >  > > "Steve French" <smfrench at gmail.com> 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 at redhat.com>
> >  > >
> >  >
> >  > 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.
> 
> 

Right, but we don't do filemap_fdatawait() on flush so I suppose we're
not guaranteed to actually have all the writes out on the wire before
the close occurs.

IIRC, the current writepages implementation in cifs I think does
effectively wait until all the writes have completed before returning,
so a filemap_fdatawait wouldn't really do make any difference.

Anyway, after looking back over the original problem, I think I'm
convinced that your original patch is OK.

ACK

Thanks,
-- 
Jeff Layton <jlayton at redhat.com>