under the new setup a kworker thread used 10-12% CPU while compiling. I'm
guessing that is the workload.
Sadly, bind mount can also mount files, which aufs cannot, so I have a bit
more work-around to do, but I think I'll manage.
Sam
On Wed, Sep 7, 2011 at 1:44 PM, Michael S. Zick <[1]a...@morethan.org>
wrote:
On Wed September 7 2011, Sam Liddicott wrote:
> I found that I could overlap my cow directories, so I have multiple aufs
> mounts, I aufs mount onto a subdirectory of a previous aufs mount, with
the
> cow being the same subdirectory of the previous cow.
>
> I get new whitelists, but otherwise I'm happy.
>
That sounds like it behaves fairly close to your other setup.
Any chance to see if the new setup is running the same 50% cpu overhead?
It might be interesting to know, if you have a chance to check the new
setup.
Mike
> Sam
>
> On Wed, Sep 7, 2011 at 12:12 PM, Sam Liddicott <[2]s...@liddicott.com>
wrote:
>
> > 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 <[3]s...@liddicott.com>
wrote:
> >
> >>
> >> On Wed, Sep 7, 2011 at 11:30 AM, <[4]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
> >>
> >
> >
>
--------------------------------------------------------------------------
----
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.
[5]http://www.accelacomm.com/jaw/sfnl/114/51434361/
References
1. mailto:a...@morethan.org
2. mailto:s...@liddicott.com
3. mailto:s...@liddicott.com
4. mailto:sf...@users.sourceforge.net
5. http://www.accelacomm.com/jaw/sfnl/114/51434361/
------------------------------------------------------------------------------
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/
