public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: hooanon05@yahoo.co.jp
To: "David P. Quigley" <dpquigl@tycho.nsa.gov>
Cc: Theodore Tso <tytso@mit.edu>, Tomas M <tomas@slax.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: New filesystem for Linux kernel
Date: Wed, 25 Feb 2009 00:41:28 +0900	[thread overview]
Message-ID: <14799.1235490088@jrobl> (raw)
In-Reply-To: <1235488695.15148.49.camel@moss-terrapins.epoch.ncsc.mil>


Hi David,
I'm glad if you remember me still.

"David P. Quigley":
> 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.

As I wrote in aufs2 documents, UnionMount may eliminate some
duplication, but it won't be able to share branches.
----------------------------------------------------------------------
UnionMount's approach will be able to small, but may be hard to share
branches between several UnionMount since the whiteout in it is
implemented in the inode on branch filesystem and always
shared. According to Bharata's post, readdir does not seems to be
finished yet.
----------------------------------------------------------------------

Anyway, "kernel people including Christoph have voiced their opinion
that they don't want to see a file system solution to union mounts" is
very impotant. If it is true, I should ask its reason fist. Could you
tell me the source of this information? Url of mail archive or somthing?


> 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

I am afraid you are confusing aufs1 and aufs2.
And I hope that such "unacceptable" things are dropped from aufs2.


> 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.

Ok, I'll wait.


J. R. Okajima

  reply	other threads:[~2009-02-24 15:42 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
2009-02-24 15:41             ` hooanon05 [this message]
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=14799.1235490088@jrobl \
    --to=hooanon05@yahoo.co.jp \
    --cc=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