KNOWN Unionfs 2.x ISSUES: ========================= 1. Unionfs should not use lookup_one_len() on the underlying f/s as it confuses NFSv4. Currently, unionfs_lookup() passes lookup intents to the lower file-system, this eliminates part of the problem. The remaining calls to lookup_one_len may need to be changed to pass an intent. We are currently introducing VFS changes to fs/namei.c's do_path_lookup() to allow proper file lookup and opening in stackable file systems. 2. Lockdep (a debugging feature) isn't aware of stacking, and so it incorrectly complains about locking problems. The problem boils down to this: Lockdep considers all objects of a certain type to be in the same class, for example, all inodes. Lockdep doesn't like to see a lock held on two inodes within the same task, and warns that it could lead to a deadlock. However, stackable file systems do precisely that: they lock an upper object, and then a lower object, in a strict order to avoid locking problems; in addition, Unionfs, as a fan-out file system, may have to lock several lower inodes. We are currently looking into Lockdep to see how to make it aware of stackable file systems. For now, we temporarily disable lockdep when calling vfs methods on lower objects, but only for those places where lockdep complained. While this solution may seem unclean, it is not without precedent: other places in the kernel also do similar temporary disabling, of course after carefully having checked that it is the right thing to do. Anyway, you get any warnings from Lockdep, please report them to the Unionfs maintainers. For more information, see <http://unionfs.filesystems.org/>.