On Wed, Mar 03, 2010 at 06:28:49PM +0100, Miklos Szeredi wrote: > On Tue, 2 Mar 2010, Valerie Aurora wrote: > > This is a major rewrite of parts of union mounts, in particular the > > pathname lookup code. For more info about union mounts, see: > > > > http://valerieaurora.org/union/ > > > > The previous code had two important problems fixed in this series: > > > > - On file open, is_unionized() grabs vfsmount lock and walks up the > > mount tree even for non-union mounts. > > > > - Pathname lookup required three cut-n-pasted versions of two complex > > functions, one for each of cached/real/"hashed" lookups. > > Looks much better :) Thanks for the review. :) > > This rewrite reduces the additional cost of a non-union lookup in a > > CONFIG_UNION_MOUNT kernel to either 1 or 2 mount flag tests (but adds > > the requirement that file systems be unioned only at their root > > directories). This rewrite implements lookup with one lookup_union() > > function for all types of lookups. > > > > This posted patch series includes only the union lookup, mount, and > > readdir patches and not the relatively uncontroversial whiteout and > > fallthru code. > > Special inode/dentry flags (whiteout, fallthrough, opaque) are not > trivially the right solution: > > - they are invisible from userspace, new APIs are necessary to manipulate them > - they are difficult to support on network filesystems > - they are not useful for anything other than union mounts/filesystems > > Extended attributes are a more standard way to add such info to files. > Hard links would allow sharing a single inode for all whiteout entries > and one for all fallthrough entries. > > Have these options been considered as an alternative? Thanks for bringing that up! We have considered them and aren't sure what the best solution is - all the options, including our current example implementations, have serious drawbacks. Fortunately, the implementation of whiteouts, etc. is fairly separate from the main body of union mount code. For example, I'm pretty sure you could implement whiteouts, fallthrus, and opaque flags in ext2 as system extended attributes or as hard links (or as crazy special symlinks) without changing any other non-ext2 patches. We already switched once from encoding whiteouts with reserved inode numbers in ext3 to whiteouts as a new dentry type flag in ext2 and that didn't affect other patches. In general, I am happy with whatever the maintainer of the underlying file system prefers. The advantage of the system extended attribute approach is that any file system with xattrs also supports union mounts. It might be worth implementing for that reason alone. -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
