I've been encountering the "dir is overlapped" error when using aufs. I'd like to point out there are some scenarios where the "overlap" is desirable, and not harmful.
I have the following setup: / # the root is an aufs union of below /mnt/root_ro # this is a read only squashfs /mnt/root_rw # this is either a tmpfs or mounted disk partition If you're wondering how I achieved this... 1. Early after boot, creating union the root mount is initially the squashfs from initrd. > /bin/mount -n -t aufs aufs /mnt/root -o br=/mnt/root_rw=rw:/mnt/root_ro=rr Mounts: / # squashfs /mnt/root_ro # squashfs (mount new squashfs from disk, so later initrd can be freed). /mnt/root_rw # a tmpfs is mounted here /mnt/root # union of above /mnt/root/oldroot # empty dir for next step 2. Pivot > /bin/pivot_root /mnt/root /mnt/root/mnt/oldroot > cd / Mounts: / # aufs union as root /mnt/oldroot/* # the initrd squashfs /mnt/oldroot/mnt/* # the previous mount points 3. Move all mount points > mount --move /mnt/oldroot/mnt/root_rw /mnt/root_rw > ... (don't forget /proc and /sys) > umount -l /mnt/oldroot # lazy unmount because still has files open (lib/*) until exec > rmdir /mnt/oldroot Mounts: / /mnt/root_ro /mnt/root_rw Now, this works exactly as I want it to. However, when I try to manipulate the union, I get the darned overlap error. > mount -t aufs aufs / -o remount,del:/mnt/root_rw > # here, warning about not being writable, which is ok > umount /mnt/root_rw > mount /dev/something /mnt/root_rw > mount -t aufs aufs / -o remount,prepend:/mnt/root_rw=rw > # [ 232.725714] aufs test_add:237:mount[1601]: /mnt/root_rw is overlapped Therefor aufs can be cleverly tricked into the desired state via pivot_root, yet refuses enter the same state when asked to. It seems to me the state should either be allowed, or not allowed. The overlapped issue is meant to protect from recursive or illogical union problems, however I believe aufs is being too aggressive with the overlap error. Test Case A # Normal dir union > mount -t aufs aufs union -o br:dir_a:dir_b Works Test Case B # Normal mount union > mount -t aufs aufs union -o br:dir_a:mnt_x Works Test Case C # inner dir > mount -t aufs aufs union -o br:dir_a:dir_a/dir_b Returns overlap error # This overlap creates an ambiguity problem: which dir does a given inode refer to in the union? # aufs cannot possibly tell the difference. # Even if this worked, a union between a dir and it's child is illogical Test Case D # Normal mount with inner mount > mount -t tmpfs tmpfs dir_a/mnt_x > mount -t aufs aufs union -o br:dir_a:dir_b Works # The union does not cross the mount boundary # A listing on union/mnt_x/* returns unmounted dir_a/mnt_x/* entries, and not the mounted ones. Test Case E # inner mount > mount -t aufs aufs union -o br:dir_a:dir_a/mnt_b Returns overlap error, but why? # Conceptually identical to test case B with regards to inodes, except that case works. # The mount location of mnt_b is completely arbitrary. # Why should the fact that it's mounted under dir_a prevent it from being unioned? # Case D shows that aufs won't follow inner mounts, illogical parent/child unions don't happen. The aufs source reveals that only paths are checked without regards to whether they form a parent/child relationship in the underlying file system. I modified the source to so it only rejects subdirectories inside one file system (the illogical case), and allows children from different mount points. Essentially I added one line to dcsub.c in au_test_subdir(): (I'm not sure if this is the proper place to make the change, but it works) if (d1->d_sb != d2->d_sb) return 0; Now aufs works for Test Case E. I've been using it without issues so far. It also solves my original problem of manipulating the root union. Is this a bad idea for any reason over my head right now? Given that this code path is currently returning an error, it's unlikely to break any working setups. Is there a chance this change can get merged? Sorry about the verbosity, I wanted to make a convincing case for this change in my initial post. Lou Gosselin ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first