From: Trond Myklebust Subject: Re: NFS v3 cached directory content out of sync Date: Tue, 25 Aug 2009 15:12:19 -0400 Message-ID: <1251227539.25372.35.camel@heimdal.trondhjem.org> References: <1250880591.27154.18.camel@heimdal.trondhjem.org> <1250962724.8143.29.camel@heimdal.trondhjem.org> <1251115893.6325.23.camel@heimdal.trondhjem.org> <1251226809.25372.29.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]:56299 "EHLO mail-out1.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751081AbZHYTMT (ORCPT ); Tue, 25 Aug 2009 15:12:19 -0400 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: 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).