From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valerie Aurora Subject: Re: NFS hard read-only mount option - again Date: Thu, 6 May 2010 11:01:32 -0400 Message-ID: <20100506150132.GB20761@shell> References: <20100426235832.GB13549@shell> <20100427075159.0fd267e4@tlielax.poochiereds.net> <20100428200746.GB16691@shell> <20100428163447.78a8eaff@tlielax.poochiereds.net> <20100428205600.GB21875@fieldses.org> <20100504225156.GA4108@shell> <20100505092230.574c2de2@corrin.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "J. Bruce Fields" , linux-fsdevel@vger.kernel.org, Trond Myklebust To: Jeff Layton Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27506 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753757Ab0EFPCH (ORCPT ); Thu, 6 May 2010 11:02:07 -0400 Content-Disposition: inline In-Reply-To: <20100505092230.574c2de2@corrin.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, May 05, 2010 at 09:22:30AM +0200, Jeff Layton wrote: > On Tue, 4 May 2010 18:51:56 -0400 > Valerie Aurora wrote: > > > > This is definitely going in the right direction, thank you. Mainly > > I'm just really ignorant of actual NFS implementation. :) > > > > Let's focus on detecting a write to a file or directory the client has > > read and still has in cache. This would be the case of an NFS dentry > > in cache on the client that is written on the server. So what is the > > actual code path if the client has an NFS dentry in cache and it is > > altered or goes away on the client? Can we hook in there and disable > > the union mount? Is this a totally dumb idea? > > > > -VAL > > Well...we typically can tell if an inode changed -- see > nfs_update_inode for most of that logic. Note that the methods we use > there are not perfect -- NFSv2/3 rely heavily on timestamps and if the > server is using a filesystem with coarse-grained timestamps (e.g. ext3) > then it's possible for things to change and the client won't notice > (whee!) > > Dentries don't really change like inodes do, but we do generally check > whether they are correct before trusting them. That's done via the > d_revalidate methods for NFS. Mostly that involves checking whether the > directory that contains the it has changed since the dentry was spawned. > > That's probably where you'll want to place your hooks, but I wonder > whether it would be better to do that at a higher level -- in the > generic VFS. Whenever a d_revalidate op returns false, then you know > that something has happened. My gut feeling is that you are right and the VFS call of the d_revalidate op is the right place to check this. My guess is that ->d_revalidate() should never fail in the lower/read-only layers of a union mount, no matter what the file system is. Can you think of a d_revalidate implementation that would fail for a reason other than a write on the server? Thanks, -VAL