Re: Union mounts, NFS, and locking

Erez Zadok
2009-07-14T18:19:54Z

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 :-)

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.).

For example, I cannot see how this can be solved cleanly and *portably* for
established protocols such as nfsv2/3. For v4, it might be possible to
enforce it with new callbacks which can propagate from the v4 client all the
way up to the VFS (and thus Union Mounts). If you're going to try and
tackle the cache-coherency beast, I strongly suggest restricting the problem
to something as "simple" and manageable as a new NFSv4 CB.

Cheers,
Erez.