On Tue, 4 May 2010 18:51:56 -0400 Valerie Aurora <vaurora@xxxxxxxxxx> wrote: > 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 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. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
