From: Trond Myklebust Subject: Re: NFS v3 cached directory content out of sync Date: Tue, 25 Aug 2009 15:25:50 -0400 Message-ID: <1251228350.25372.36.camel@heimdal.trondhjem.org> References: <1250962724.8143.29.camel@heimdal.trondhjem.org> <1251115893.6325.23.camel@heimdal.trondhjem.org> <1251226809.25372.29.camel@heimdal.trondhjem.org> <1251227539.25372.35.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain Cc: linux-nfs To: Stefan Egli Return-path: Received: from mail-out1.uio.no ([129.240.10.57]:32858 "EHLO mail-out1.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755936AbZHYTZv (ORCPT ); Tue, 25 Aug 2009 15:25:51 -0400 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: 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/ Cheers Trond