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