> I was just re-reading the linux-fsdevel archives from june of 2000.> I'm guessing the reason you're not getting a response from Al is that> he never did unionfs. He did union mounts, and made clear that they> are not related. Union mounts would only work at the top level, the> union would not recurse down the (union-)mounted trees.

(Reading that thread...)

OK, now I understand better. Although I can't find any code/patch forunion mount either.

> Performance-wise this could become very, very slow very quickly, but> if we replace the vfsmount which is found by using> mount_hashtable + hash(vfsmnt, dentry) to find what is mounted on top> of a particular dentry with a vfsmount_stackable struct, which contains,> say,> > struct vfsmount_stackable {> struct vfsmount *vfsmnt;> int mount_flags; /* 1 = read, 2 = write, 3 = hide */> struct vfsmount_stackable *next;> };> > then perhaps it might be reasonably simple to have __follow_down and> follow_mount make use of this structure. We make sure to keep the> vfsmount_stackable list in order mounted priority, so that when we> come to one of these lists, we can just do something like> > while (vfsmount_stacked) {> ret = stacked_lookup(vfsmount_stacked->vfsmnt, vfsmnt_stacked->dentry,> remaining_pathname);> if (ret)> return ret;> vfsmnt_stacked = vfsmnt_stacked->next;> }> > return NULL;> > Thoughts?

Yes, this sounds like a good way to implement a unionfs-likefunctionality. Something a bit more general would be to have apath_walk(const char *remaining_path, struct nameidata *nd) operationof vfsmount, which if non-null would be used to perform the rest ofthe lookup. This could then perform the looped lookup trials youdescribe, but could be used for other special lookup methods.