On Mon, 26 Apr 2010 19:58:33 -0400 Valerie Aurora <vaurora@xxxxxxxxxx> wrote: > I want to restart the discussion we had last July (!) about an NFS > hard read-only mount option. A common use case of union mounts is a > cluster with NFS mounted read-only root file systems, with a local fs > union mounted on top. Here's the last discussion we had: > > http://kerneltrap.org/mailarchive/linux-fsdevel/2009/7/16/6211043/thread > > We can assume a local mechanism that lets the server enforce the > read-only-ness of the file system on the local machine (the server can > increment sb->s_hard_readonly_users on the local fs and the VFS will > take care of the rest). > > The main question is what to do on the client side when the server > changes its mind and wants to write to that file system. On the > server side, there's a clear synchronization point: > sb->s_hard_readonly_users needs to be decremented, and so we don't > have to worry about a hard readonly exported file system going > read-write willy-nilly. > > But the client has to cope with the sudden withdrawal of the read-only > guarantee. A lowest common denominator starting point is to treat it > as though the mount went away entirely, and force the client to > remount and/or reboot. I also have vague ideas about doing something > smart with stale file handles and generation numbers to avoid a > remount. This looks a little bit like the forced umount patches too, > where we could EIO any open file descriptors on the old file system. > > How long would it take to implement the dumb "NFS server not > responding" version? > > -VAL Ok, so the problem is this: You have a client with the aforementioned union mount (r/o NFS layer with a local r/w layer on top). "Something" changes on the server and you need a way to cope with the change? What happens if you do nothing here and just expect the client to deal with it? Obviously you have the potential for inconsistent data on the clients until they remount along with problems like -ESTALE errors, etc. For the use case you describe however, an admin would have to be insane to think that they could safely change the filesystem while it was online and serving out data to clients. If I had a cluster like you describe, my upgrade plan would look like this: 1) update a copy of the master r/o filesytem offline 2) test it, test it, test it 3) shut down the clients 4) unexport the old filesystem, export the new one 5) bring the clients back up ...anything else would be playing with fire. Unfortunately I haven't been keeping up with your patchset as well as I probably should. What happens to the r/w layer when the r/o layer changes? Does it become completely invalid and you have to rebuild it? Or can it cope with a situation where the r/o filesystem is changed while the r/w layer isn't mounted on top of 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
