From: "David P. Quigley" <dpquigl@tycho.nsa.gov>
To: Theodore Tso <tytso@mit.edu>
Cc: Tomas M <tomas@slax.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: New filesystem for Linux kernel
Date: Tue, 24 Feb 2009 10:18:15 -0500 [thread overview]
Message-ID: <1235488695.15148.49.camel@moss-terrapins.epoch.ncsc.mil> (raw)
In-Reply-To: <20090224141548.GB5482@mit.edu>
On Tue, 2009-02-24 at 09:15 -0500, Theodore Tso wrote:
> On Tue, Feb 24, 2009 at 09:13:08AM +0100, Tomas M wrote:
> > An overview of aufs2 has been submitted to this list.
> > I noticed zero response at all. Nobody cares?
> >
> > I suggest to remove unionfs from Andrew's -mm tree and replace it by aufs2!
> > Tell me why this should not happen...
>
> Um, you need to tell us why aufs2 is better than Unionfs. The burden
> of proof rests on your shoulders. The code which is displacing
> existing code needs to give a justification about why it is better
> than the code which is displacing, not the other way around.
>
> > I write this in the hope that a debate will start...
>
> As a debate judge might say, you haven't even made your prima facie
> case yet.
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
The arguments that the AUFS2 people have been using for a while is that
aufs2 is more stable than unionfs. I use to work on the Stony Brook
version of Unionfs and I must admit that the 1.0 version which I did the
initial 2.6 kernel port of was buggy. However after I left they rewrote
large chunks of the code for a 2.0 release. I don't have much knowledge
of this code base but I am still subscribed to the Unionfs mailing list
and I don't see too many bug reports heading that way.
In reality though the debate isn't Unionfs vs AUFS2 because many of the
kernel people including Christoph have voiced their opinion that they
don't want to see a file system solution to union mounts. There have
been patch sets trying to introduce union mounts and they seem to have
gone quiet for a while as one of the main points of debate was how and
where to do duplicate elimination.
That being said there is no reason that both unionfs and aufs2 can't
live in mm. However, just because either of them are in mm doesn't mean
that they will get mainlined. Reiser4 has been in there for ages and I
don't think anyone sees that getting in any time soon.
As far as review of AUFS2 goes I use to idle in a few freenode channels
a while back and there was a discussion about AUFS2 the first time it
hit LKML. The AUFS people tout that the unionfs dev team has
incorporated some of their ideas into unionfs and that is true. However,
one of the issues raised about AUFS back then was that they had all
sorts of sorted hacks that were unacceptable for use in mainline. I
don't have my irc logs since I am at work and they are at home but I can
try to dig up the specific problems when I get home later today.
I think AUFS2 really needs a solid review but as other people have said
it isn't broken up and organized in a way that makes it a task someone
wants to do. Earlier in the thread someone said that the AUFS team needs
to slim it down to just core features and get those mainlined. The
Unionfs team did this when we were moving for mainline inclusion and I
think that is one of the reasons why people jumped ship and moved to
AUFS. Since we were focusing on the mainline inclusion effort and
releasing a smaller feature set Unionfs it ended up dropping some
functionality that people may have seen as core while the kernel
community and ourselves didn't.
Just my $0.02 and in no way shape or form the opinion of my employer or
the US govt and definitely not a request to have work done in this
space.
next prev parent reply other threads:[~2009-02-24 15:21 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 7:31 [RFC 0/8] Aufs2 documents hooanon05
2009-02-23 7:33 ` [RFC 1/8] Aufs2: introduction hooanon05
2009-02-23 7:34 ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23 9:13 ` Tomas M
2009-02-23 9:22 ` Tomas M
2009-02-24 8:13 ` New filesystem for Linux kernel Tomas M
2009-02-24 11:52 ` Miklos Szeredi
2009-02-24 13:18 ` hooanon05
2009-02-24 13:45 ` Tarkan Erimer
2009-02-24 13:57 ` hooanon05
2009-02-24 14:16 ` Tarkan Erimer
2009-02-24 14:50 ` Miklos Szeredi
2009-02-24 16:26 ` hooanon05
2009-02-25 10:28 ` Miklos Szeredi
2009-02-26 4:09 ` hooanon05
2009-02-26 5:51 ` hooanon05
2009-02-26 5:55 ` hooanon05
2009-02-24 14:15 ` Theodore Tso
2009-02-24 15:18 ` David P. Quigley [this message]
2009-02-24 15:41 ` hooanon05
2009-02-25 15:53 ` David P. Quigley
2009-02-26 4:21 ` hooanon05
2009-02-25 7:31 ` Tomas M
2009-02-25 9:33 ` David Newall
2009-02-25 8:12 ` Tomas M
2009-02-26 14:31 ` Amit Kucheria
2009-02-23 14:23 ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23 7:35 ` [RFC 3/8] Aufs2: lookup hooanon05
2009-02-23 7:36 ` [RFC 4/8] Aufs2: branch hooanon05
2009-02-23 7:36 ` [RFC 5/8] Aufs2: wbr_policy hooanon05
2009-02-23 7:37 ` [RFC 6/8] Aufs2: fmode_exec hooanon05
2009-02-23 7:37 ` [RFC 7/8] Aufs2: mmap hooanon05
2009-02-23 9:18 ` Tomas M
2009-02-23 14:39 ` hooanon05
2009-02-23 7:38 ` [RFC 8/8] Aufs2: plan hooanon05
2009-02-25 17:50 ` [RFC 0/8] Aufs2 documents David P. Quigley
2009-02-25 19:07 ` Matthew Wilcox
2009-02-26 4:54 ` hooanon05
2009-02-26 17:20 ` David P. Quigley
2009-02-27 14:27 ` hooanon05
2009-02-27 18:17 ` David P. Quigley
2009-02-28 8:04 ` hooanon05
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=1235488695.15148.49.camel@moss-terrapins.epoch.ncsc.mil \
--to=dpquigl@tycho.nsa.gov \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tomas@slax.org \
--cc=tytso@mit.edu \
/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).