From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: NFS hard read-only mount option - again Date: Wed, 28 Apr 2010 16:56:00 -0400 Message-ID: <20100428205600.GB21875@fieldses.org> References: <20100426235832.GB13549@shell> <20100427075159.0fd267e4@tlielax.poochiereds.net> <20100428200746.GB16691@shell> <20100428163447.78a8eaff@tlielax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Valerie Aurora , linux-fsdevel@vger.kernel.org, Trond Myklebust To: Jeff Layton Return-path: Received: from fieldses.org ([174.143.236.118]:38604 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751337Ab0D1U4E (ORCPT ); Wed, 28 Apr 2010 16:56:04 -0400 Content-Disposition: inline In-Reply-To: <20100428163447.78a8eaff@tlielax.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Apr 28, 2010 at 04:34:47PM -0400, Jeff Layton wrote: > On Wed, 28 Apr 2010 16:07:46 -0400 > Valerie Aurora wrote: > > > > > What I need can be summarized in the distinction between the following > > scenarios: > > > > Scenario A: The NFS server reboots while a client has the file system > > mounted as the r/o layer of a union mount. The server does not change > > the exported file system at all and re-exports it as hard read-only. > > This should work. > > > > Nitpick: This should be fine regardless of how it's exported. You > don't want the clients going bonkers just because someone pulled the > plug on the server accidentally. NFS was designed such that clients > really shouldn't be affected when the server reboots (aside from > stalling out on RPC calls while the server comes back up). > > > Scenario B: The NFS server reboots as in the above scenario, but > > performs "touch /exports/client_root/a_file" before re-exporting the > > file system as hard read-only. This is _not_ okay and in some form > > will cause a panic on the client if the client doesn't detect it and > > stop accessing the mount. > > > > How to tell the difference between scenarios A and B? > > > > I don't believe you can, at least not with standard NFS protocols. I > think the best you can do is detect these problems on an as-needed > basis. Anything that relies on server behavior won't be very robust. Yeah. Even if the server had a way to tell the client "this filesystem will never ever change, I promise" (and actually I think 4.1 might have something like that--see STATUS4_FIXED?)--there's still so many opportunities for operator error, network problems, etc., that in pratice a client that panics in that situation probably isn't going to be considered reliable or secure. So the unionfs code has to be prepared to deal with the possibility. If dealing with it fairly harshly is the simplest thing to do for now, I agree, that sounds fine--but panicking sounds too harsh! I'm not sure if we're answering your question. --b.