On Wed, Apr 28, 2010 at 04:34:47PM -0400, Jeff Layton wrote: > On Wed, 28 Apr 2010 16:07:46 -0400 > Valerie Aurora <vaurora@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
