Re: Union mounts, NFS, and locking

[Valerie Aurora <vaurora@redhat.com>]

On Tue, Jul 14, 2009 at 02:19:26PM -0400, Erez Zadok wrote:
> In message <20090714174828.GE27582@shell>, Valerie Aurora writes:
> [...]
> > (Yes, this depends on the actual concrete union mount locking scheme,
> > but I'm more interested in whether it can or cannot be solved in
> > principle.)
> 
> Val,
> 
> To solve this "in principle" would require a semantic change to all
> network-based file systems (not just NFS).  You'll find yourself deep inside
> age-old distributed systems and distributed locking issues---hard problems
> (you've got plenty to worry about w/o having to redefine NFS semantics :-)

Makes sense.

> IMHO it's not worth at this stage to try and solve that problem in an
> end-to-end manner (client to server).  For a unioning layer to have to worry
> about every possible change in any of the layers below it, is no different
> than for every possible network-filesystem client to be able to guarantee
> that nothing ever changes on the server unexpectedly: they don't, so why
> should you have to solve this problem now?  Not that I don't think it's an
> important problem---I just don't see why *you* should have to solve this and
> not the network-filesystem community: whatever solution that can come up,
> can be applicable to any unioning layer.  In the mean time, do the best you
> can (e.g., ESTALE, readonly superblocks, etc.).

Okay, so my best idea for a solution is to introduce a new NFS mount
option that means the server promises that the exported file system is
read-only (using superblock read-only count scheme locally).  E.g.:

/etc/exports:
/client_root_fs   thin-client-*.local.domain(server_ro,no_root_squash)

Trond, is this super-gross or totally reasonable?  Seems like we add
new NFS mount options at the drop of a hat.

-VAL