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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
