From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: jblunck@suse.de
Subject: Heads up on VFS based union mount
Date: Fri, 30 Mar 2007 15:38:54 +0530 [thread overview]
Message-ID: <20070330100854.GD16104@in.ibm.com> (raw)
The need for a unified/merged view of two or more filesystems/directories
has been felt for sometime now. Though a few out-of-the-kernel solutions
existed for this, it is only recently that the unionfs(1) solution has gone
into -mm. At the time of merging unionfs into -mm, a few questions were
raised about the appropriateness of having this namespace unification
feature as a separate stackable file system. Encouraged by this comment
from Andrew (http://lkml.org/lkml/2007/1/8/280) and also the interest about
unionfs in recently concluded Linux Storage and Filesystem Workshop(2),
I started looking into Jan Blunck's 2004 diploma thesis work where he had
implemented a VFS based union mount feature. Now Jan and I are working
towards moving this to latest kernel and bringing it to a stage that it
can posted as an RFC. While we are at it, we thought lets give a heads up
on our union mount effort and try to get some early feedbacks/opinions.
While unionfs implements a new filesystem and maintains a set
of VFS objects which stack the real VFS objects under them to get the
unification feature, union mount achieves the same stacking with
minimal (atleast conceptually minimal) changes at the VFS layer.
In union mount approach we maintain this stacking information in the
dentry structure. When a filesytem is union mounted on a mountpoint,
the dentry of the mount root would hold a reference to the mountpoint
dentry as an overlaid dentry and these two dentries together form
a union stack. Any subsequent readdir operation on this union mounted
dentry would work on the overlaid dentry also thereby providing the
merged view of the two filesystems.
Since the stacking information is maintained at the VFS layer, union
mount makes some heavy changes to the VFS lookup code and minor changes
to many VFS routines. Also the whiteout filetype is handled in kernel
and the physical filesytem is expected to support the new whiteout file type.
For copyup, we are right now using a hack of pipe/splice to get the
in-kernel file copy between two layers.
We are planning to post the RFC code pretty soon. More documentation
about the approach would accompany the code.
(1) Unionfs: http://www.filesystems.org/project-unionfs.html
(2) LWN article on LSF07: http://lwn.net/Articles/226351/
Regards,
Bharata.
next reply other threads:[~2007-03-30 10:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-30 10:08 Bharata B Rao [this message]
2007-03-30 19:04 ` Heads up on VFS based union mount Jan Engelhardt
2007-03-31 11:09 ` Bharata B Rao
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=20070330100854.GD16104@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=jblunck@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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