On Feb 11, 2015, at 6:03 AM, David Howells <dhowells@xxxxxxxxxx<mailto:dhowells@xxxxxxxxxx>> wrote: Caldwell, Blake A. <blakec@xxxxxxxx<mailto:blakec@xxxxxxxx>> wrote: My use case for overlayfs is a NFS (v3 or v4) lowerdir, which appears rejected by the code below because NFS defines d_revalidate, d_automount, and d_weak_revalidate (v3 only). How do you solve the file locking and fanotify problems? That's where I need your help :-) You're lkml post was helpful for me to read https://lkml.org/lkml/2015/1/26/740 NFS is a bit overkill for distributing a filesystem tree snapshot over the network, but it is an efficient way to do it. Pages are loaded into the page cache, meaning the whole image doesn't need to be transferred over the network. Coherent locking and *notify are complicating the matter, but I could see how supporting them is necessary to declare NFS support. I'm not sure what options exist for this use case, but it seems to be shared by several others. To describe the desired behavior. When node1 opens a file R/O a local read lock is sufficient. It would prevent processes local to the system from opening an overlapping write lock. If another node, node2, opens the same file R/W it should attempt to take a lock that would conflict with the lock on node1. However, it will invoke copyup on node2 and maintain a write lock. Unintended copyups need to be blocked, or (as you mentioned without proper handling) the resulting copy may lose the lock. This seems to point towards local only locks -o nlock, and trusting the cluster not to modify the filesystem (to also prevent fanotify). Given the lack of enforcement mechanisms on the client for latter, are we limited to removing that check by hand and compiling a custom kernel, or would an override "mount with possible inconsistency" option be merge-able? -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
