All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Vince Busam <vbusam@google.com>, nfs@lists.sourceforge.net
Subject: Re: mtime not updated in client cache?
Date: Fri, 09 Dec 2005 09:24:48 -0500	[thread overview]
Message-ID: <439993B0.90801@redhat.com> (raw)
In-Reply-To: <1134137783.8007.24.camel@lade.trondhjem.org>

Trond Myklebust wrote:

>On Fri, 2005-12-09 at 09:06 -0500, Peter Staubach wrote:
>  
>
>>Trond Myklebust wrote:
>>
>>    
>>
>>><looks at code>
>>>
>>>Yep. Your code contains a wrong assumption: fflush() is not guaranteed
>>>to immediately update mtime/ctime since it does not sync data to disk.
>>>The same is true of the posix "write()" function.
>>>
>>>If you add the line fsync(fileno(fp)) after the call to fflush(), then
>>>the mtime will be correctly updated.
>>>
>>>      
>>>
>>Perhaps I am missing something, but fsync(2) should not cause the 
>>mtime/ctime
>>to change.  The write(2) call should.  Sequences such as 
>>stat(&a)/write()/stat(&b)
>>should result b.st_mtime != a.st_mtime.
>>    
>>
>
>If you are caching the write on the client, then the server will not
>update the mtime on the file.
>
>OTOH, I do not like the idea of updating mtime on the client, since
>there is no guarantee that the client and server are synchronised (you
>can easily end up with the mtime jumping forwards and backwards).
>
>One alternative would be to flush dirty data to the server on every call
>to stat(), but that would slow it down considerably.
>

Yes, to this last, but this is how most NFS implementations that I have seen
conform to the requirment that write(2) cause the mtime to be updated.  The
use of UNSTABLE NFSv3/NFSv4 writes can help as well as limiting the amount
of dirty data that the client allows to be cached.

The client should _definitely_ not be setting the mtime itself.  The 
file times
are always managed by the server.

    Thanx...

       ps


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-12-09 14:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-29  0:09 mtime not updated in client cache? Vince Busam
2005-11-29  0:45 ` Trond Myklebust
2005-12-01  1:06   ` Vince Busam
2005-12-01  1:15     ` Trond Myklebust
2005-12-08  1:22       ` Vince Busam
2005-12-08  3:38         ` Trond Myklebust
2005-12-09 14:06           ` Peter Staubach
2005-12-09 14:16             ` Trond Myklebust
2005-12-09 14:24               ` Peter Staubach [this message]
2005-12-09 15:19                 ` Trond Myklebust
2005-12-13  1:51                   ` Vince Busam
  -- strict thread matches above, loose matches on Subject: below --
2005-12-09 15:56 Lever, Charles
2005-12-09 16:10 ` Trond Myklebust
2005-12-09 16:40 ` Peter Staubach
2005-12-09 19:07 Lever, Charles
2005-12-09 19:20 ` Peter Staubach
2005-12-09 19:55   ` Roger Heflin
2005-12-09 21:05     ` Peter Staubach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=439993B0.90801@redhat.com \
    --to=staubach@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    --cc=vbusam@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.