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

Guenter Kukkukk linux at kukkukk.com
Fri Mar 14 22:52:55 GMT 2008


Am Freitag, 14. März 2008 schrieb Jeff Layton:
> 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?
> 
> 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...
> 

as far as i have tested, recent windows servers even dis-allow the sequence
open()
write()
utimes()  (via setpathinfo)
close()

when open() and write() have been done already, setpathinfo is simply
_ignored_ (but the server returns "success")!
This also "smells" a bit like write caching... on the windows server side.
I have taken sniffs to watch the right order on the wire.
Cheers, Günter


More information about the linux-cifs-client mailing list