I must be a liar. While I did a test as I described and it worked, I can't
re-produce it.
Sam
On Wed, Sep 7, 2011 at 11:54 AM, Sam Liddicott <[1]s...@liddicott.com> wrote:
On Wed, Sep 7, 2011 at 11:30 AM, <[2]sf...@users.sourceforge.net> wrote:
Sam Liddicott:
> With unionfs-fuse I had my read only tree in two parts, one was a complete
> chrootable root build environment filesystem, and one was project build
> sources. Both have different origins and aren't easily combined. The
project
> sources need splicing into a subdirectory of the build environment
...
For two RO mounts, you need two RW dirs and two aufs mounts.
For instance,
# mount -t aufs -o br:/rw1:/ro1 /aufs
# mount -t aufs -o br:/rw2:/ro2 /aufs/sub-aufs
As you wrote, aufs doesn't follow-down the sub-mounts in the branch
which is a "bind" behaviour instead of "rbind". It is a specification of
aufs.
Thanks for the quick answer. I see that this makes sense, but I want to have
a single cow for my composed chroot file system.
I have found a way around the problem which perhaps you will patch now I
tell you :-)
Having composed my read-only root file system using bind-mounts I can then
make yet another directory onto which I rbind mount my composed root.
I then mount that with aufs.
because aufs doesn't scrutinise such mount paths deeply this works nicely,
at the cost of an extra directory. It also keeps my chrootly script having a
similar form whether it uses aufs or falls back to unionfs.
Thanks for your work on aufs, I appreciate it.
Sam
References
1. mailto:s...@liddicott.com
2. mailto:sf...@users.sourceforge.net
------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
