Message-ID: <344eb09a0706202225i6743159x68e3a5416850eed3@mail.gmail.com>
Date:	Thu, 21 Jun 2007 10:55:45 +0530
From:	"Bharata B Rao" <bharata.rao@...il.com>
To:	"Erez Zadok" <ezk@...sunysb.edu>
Cc:	"Jan Blunck" <jblunck@...e.de>, linux-kernel@...r.kernel.org,
	jsipek@...sunysb.edu, bharata@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH 1/4] Union mount documentation.

On 6/20/07, Erez Zadok <ezk@...sunysb.edu> wrote:
> In message <f5al1i$foi$1@....gmane.org>, Jan Blunck writes:
> > On Tue, 19 Jun 2007 22:59:51 -0700, Arjan van de Ven wrote:
> >
> > > first of all I'm happy to see that people are still working on unionfs;
> > > I'd love to have functionality like this show up in Linux.
> >
> > This has nothing to do with unionfs. This is about doing a VFS based
> > approach to union mounts. Unification is a name-based construct so it
> > belongs into VFS and not into a separate file system.
>
> Jan, while I agree with you in principle that unification is a VFS-level
> namespace construct, I disagree with you that unioning doesn't belong in a
> separate f/s.
>
> As someone whose group developed three generations of the stackable file
> system Unionfs (see http://unionfs.filesystems.org/), I can tell you from my
> experience and the experience of numerous users, that the devil is the
> details -- or the so-called orthogonal issues.  To get a fully working
> unioning implementation, one that the many current users of Unionfs could
> use, you'll have to deal with many issues and corner cases: cache coherency,
> inode persistency (and network f/s exports), copyups, whiteouts and opaque
> dirs, how to deal with "odd" file systems which don't support native
> whiteouts and such, directory reading (seekdir), and more.  Our third
> generation Unionfs, the one with On-Disk Format (ODF), handles all of these.
> Rather than reproduce all that discussion here, I'll point people to read
> more info here: <http://www.filesystems.org/unionfs-odf.txt>

Erez, thanks, will definetely have to look at that to understand how
unionfs is addressing all these corner cases.

Though I don't understand all the issues involved with cache coherency
atm, one of the things you said during unionfs 2.0 release is that it
is now possible to make modifications to the lower layer directly and
they will be visible from the union. Note that since we do unioning at
VFS layer, we don't explicitly address this. Direct
modifications/additions to the lower layer will automatically get
reflected in the union. Anyway before commenting anything more on
this, let me get back and study the coherency issues more closely :)

>
> So, to have a fully usable union mounts implementation, you're going to have
> to support a lot of existing features; but if you were to support them all
> at the VFS level, you will have bloated the VFS considerably with stuff that
> many would argue does not belong in the VFS.

Talking about copyup and whiteout at VFS layer, we have already
demonstrated what complexity it takes to have these within VFS. Please
take a look at the copyup and whiteout patches in our previous
releases at:

http://lkml.org/lkml/2007/4/17/150
http://lkml.org/lkml/2007/5/14/69

Or may be wait till I clean all those up to work with the new union
new stack infrastructure which I have posted here.

Regards,
Bharata.
-- 
"Men come and go but mountains remain" -- Ruskin Bond.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists