From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: NFS cache problem
Date: Wed, 25 May 2005 20:12:33 -0400
Message-ID: <1117066353.12336.82.camel@lade.trondhjem.org>
References: <429503BA.4060908@utwente.nl>
	 <1117064050.12336.67.camel@lade.trondhjem.org>
	 <42950DCE.9050109@utwente.nl>
Mime-Version: 1.0
Content-Type: text/plain
Cc: nfs@lists.sourceforge.net
To: Anton Starikov <A.Starikov@utwente.nl>
In-Reply-To: <42950DCE.9050109@utwente.nl>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

to den 26.05.2005 Klokka 01:44 (+0200) skreiv Anton Starikov:
> Trond Myklebust wrote:
> > The NFS cache consistency model is discussed in the FAQ. Please see
> > http://nfs.sourceforge.net/#faq_a8
> 
> I did it long time ago. I've reread it now.
> My usage fits this. I have "noac" and "sync" on client side. What's more? :)

"noac" just means that the client rereads the attributes every time it
reads or writes.
If the size and the mtime on the file haven't changed, then the client
assumes the data in the file itself also hasn't changed. That is usually
a good assumption on something like XFS (which has nanosecond precision
on mtime). It can be rather inaccurate on something like EXT3 (which has
a precision of only 1 second on mtime).

If you seriously need uncached reads and writes, then you should rather
consider using O_DIRECT.

Cheers,
  Trond


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs