For now, the union mount developers are assuming that the bottom layer of a union mount is read-only. This avoids the directory topology-related problems summarized in this thread: http://lkml.org/lkml/2008/1/17/4 The problem is making a file system really really read-only and not letting someone else come along and start sneakily modifying it underneath us. My superblock readonly users patch (http://lkml.org/lkml/2009/7/13/243) fixes that for local file systems, but I'm not sure how to handle NFS mounts as the bottom layer. The client can mount it read-only, but that puts no restrictions on the server. However, the kernel can already deal with things unexpectedly moving/going away on an NFS mount - ESTALE - and the dentry/inode/etc. won't suddenly disappear in the way they can with local file systems. Is this good enough for union mounts? Or do we need to get the NFS server to promise that the exported file system is really really read-only too? (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 unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
