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. In the above case, the mtime on /exports/client_root will (likely) have changed. At that point you can try to handle the situation without oopsing. There are quite a few ways to screw up your NFS server too that don't involve changing the underlying fs. Suppose the server is clustered and someone screws up the fsid's such that you get ESTALE's when you try to access the root inode? It would be best if union mounts could cope with that sort of problem without oopsing (even if the alternative is EIO's for everything that touches it). -- 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