On Aug 25, 2009, at 3:25 PM, Trond Myklebust wrote:
> On Tue, 2009-08-25 at 21:19 +0200, Stefan Egli wrote:
>> On Tue, Aug 25, 2009 at 9:12 PM, Trond Myklebust wrote:
>>> On Tue, 2009-08-25 at 21:06 +0200, Stefan Egli wrote:
>>>> On Tue, Aug 25, 2009 at 9:00 PM, Trond Myklebust wrote:
>>>>> Yes. The NFS client will cache mtime whether or not you do an
>>>>> 'ls'. I
>>>>> suspect the only reason for the 'ls' in that launchpad bug
>>>>> report, is to
>>>>> force an mtime update (and to fill the readdir cache).
>>>>
>>>> Ok, interesting. I guess though that 'something' needs to read at
>>>> least
>>>> a file in that particular directory for the directory content to be
>>>> cached, right? (i.e. either an 'ls' or some create/delete of a
>>>> file?)
>>>
>>> Every time you use a filename, the act of looking up that name is
>>> cached. The parent directory's mtime is also cached. If it
>>> changes, then
>>> the cached lookup is invalidated. If not, then the cached lookup is
>>> assumed still valid (since the directory contents are not supposed
>>> to
>>> have changed).
>>
>> Great thanks, got that!
>>
>> Is there some docu about this level of NFS detail you know of?
>> Esp the attribute and the data cache?
>
> There should be some information (perhaps a bit out of date, but
> most of
> it good) in the old FAQ here: http://nfs.sourceforge.net/
nfs(5) has an extensive addendum on metadata caching. An upcoming
update will document the lookupcache behavior.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Thanks Mates! I've seen those manuals but the bug I'm chasing doesn't
seem to be documented ;)
Just now that I got your attention :) one final clarification question:
* the attribute cache (==metadata cache) is part of the nfs client code
* the date (=file content) cache would be the normal linux caching
Am I on the right track there?
Cheers,
Stefan