In message <20090713192743.GA27582@shell>, Valerie Aurora writes: > During the last FS summit, Al Viro suggested creating a superblock > level read-only marker so that union mounts could guarantee that the > underlying fs would not become writable. This patch implements the > VFS support, but doesn't add any users. The patch making union mounts > use the support is in our union mounts tree. I think we also need > some way to pass this through NFS mounts, since a read-only NFS mount > for the bottom layer of a union mount is a common use case. > > -VAL [...] Val, I've often wondered if a generic readonly superblock solution will obviate the need for the sb->s_vfs_rename_mutex "kludge" (as commented in fs.h) and the whole way directory-renames are done wrt locking. Can the rename code be the first user of such patch, or the patch isn't quite ready for this? I realize that marking a whole superblock readonly during a directory rename can hurt performance in some cases, as compared to the current way of doing things, using lock_rename() to lock a subtree of the namespace. But I suspect that many concurrent directory renames are an exception, and thus practical performance won't be hurt much with such a patch -- but result in major benefits of code simplicity for several file systems (esp. for unioning layers). Erez. -- 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
