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
