Heads up on VFS based union mount
- From: Bharata B Rao <bharata@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 30 Mar 2007 15:38:54 +0530
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: Heads up on VFS based union mount
- From: Jan Engelhardt
- Re: Heads up on VFS based union mount
- Prev by Date: Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?
- Next by Date: Re: [PATCH] Use X86_EFLAGS_IF in x86-64/irqflags.h.
- Previous by thread: Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
- Next by thread: Re: Heads up on VFS based union mount
- Index(es):
Relevant Pages
|
|
