On Wed, Apr 28, 2010 at 04:56:00PM -0400, J. Bruce Fields wrote: > 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. 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 -- 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
