From: Bakul Shah <bakul@bitblocks.com>
To: 9fans@9fans.net
Subject: [9fans] union directories exploration
Date: Tue, 18 Sep 2012 23:31:27 -0700 [thread overview]
Message-ID: <20120919063127.4FD08B827@mail.bitblocks.com> (raw)
I think I understand plan9 union directories but find them
limiting for some uses. Consider
term% mkdir -p a1/b/c a1/b/d a2/b/c a2/b/e
term% touch a1/b1 a2/b2 a1/b/c1 a2/b/c2
term% du -a a1
0 a1/b1
0 a1/b/c
0 a1/b/d
0 a1/b/c1
0 a1/b
0 a1
term% du -a a2
0 a2/b/e
0 a2/b/c2
0 a2/b/c
0 a2/b
0 a2/b2
0 a2
term% bind -a a1 a2
term% du -a a2
0 a2/b/e
0 a2/b/c2
0 a2/b/c
0 a2/b2
0 a2/b1
0 a2/b
0 a2
[Note: redundant entries are deleted]
Notice that after the binding, b/d and b/c1 don't show up in
a2. This happens because b exists in both directories and
once a2/b is traversed, further search is limited to the
original a2/ tree. Even if you ls a2/b/c1, it will fail.
The behavior I want (making all the file in a1 and a2 visible
after binding, with preference to the "before" directory) can
be achieved by binding *every* in a1 directories that has a
correponding dir in a2, starting with the leaf directories and
moving up.
term% unmount a2
term% bind -a a1/b/c a2/b/c
term% bind -a a1/b a2/b
term% bind -a a1 a2
term% du -a a2
0 a2/b/e
0 a2/b/c
0 a2/b/d
0 a2/b2
0 a2/b1
0 a2/b/c2
0 a2/b/c1
0 a2/b
0 a2
[Note: redundant entries are deleted]
What I want to do idea is to overlay one tree on another.
This idea can be used to overlay a r/w tree on a readonly
source tree and do a build. Or even do a concurrent build for
different architectures. But there are hundreds of
directories in /sys so this can get quite unwieldy and a
walk(9) can become more of a shuffle or search. May be this
should be called a "labor" union!
Has anyone tried this and has a script for this? Is there a
better way to handle this (overlay one partial tree on another
to provie a different 'view')? Then there are issues with what
happens when directories are added or deleted. One almost
wants a `Watch' command that watches such changes and does the
right thing.
Since binds are only allowed on directories, deleting a file
foo in the "before" directory can make any file foo in the
"after" directory. I guess this is why *BSD unionfs has a
`whiteout' file type [this is analogous to a `blackhole' route
in a network forwarding table or a `blacklisted' email address
in a spam filter. How funny]
[Thinking about this makes me appreciate the complexity of
*BSD unionfs and why it has never been fully shaken out. May
be worth prototyping on plan9]
next reply other threads:[~2012-09-19 6:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-19 6:31 Bakul Shah [this message]
2012-09-19 6:47 ` cinap_lenrek
2012-09-19 7:42 ` Bakul Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120919063127.4FD08B827@mail.bitblocks.com \
--to=bakul@bitblocks.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).