From: "J. R. Okajima" <hooanon05@yahoo.co.jp>
To: Erez Zadok <ezk@fsl.cs.sunysb.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Miklos Szeredi <miklos@szeredi.hu>,
"viro@ZenIV.linux.org.uk Viro" <viro@ZenIV.linux.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"apw@canonical.com" <apw@canonical.com>,
"nbd@openwrt.org" <nbd@openwrt.org>,
"neilb@suse.de" <neilb@suse.de>,
"hramrach@centrum.cz" <hramrach@centrum.cz>,
"jordipujolp@gmail.com" <jordipujolp@gmail.com>,
"mszeredi@suse.cz" <mszeredi@suse.cz>
Subject: Re: [PATCH 0/7] overlay filesystem: request for inclusion
Date: Fri, 17 Jun 2011 08:41:03 +0900 [thread overview]
Message-ID: <15841.1308267663@jrobl> (raw)
In-Reply-To: <BF42D8D9-B947-448A-8818-BCA786E75325@fsl.cs.sunysb.edu>
Erez Zadok:
> My point is that Overlayfs has ENOUGH useful features NOW to be merged. =
> What stops it from going in?! More freeping creaturisms? Why do we need =
:::
As I wrote before, I have no objection about merging overlayfs or
UnionMount. My point is they have unioning feature but don't have some
of essential filesystem features. I don't think it is a trade-off or
something.
As you and other people wrote, many years passed in unioning. The very
basic features are already achieved in very early stage. The point is
how normal filesystem features are designed and implemented.
I am discussing about the design and feature of unioning, but don't stop
merging overlayfs.
> We cannot ask Overlayfs to support all of the features that other =
> solutions have, b/c it may take a very long time to get those in when =
Agreed, particularly union-specifc extra features.
Actually I am not asking overlayfs to support all features aufs has. You
may think what I am doing as a design review.
> The vast majority of unioning users want 2 layers, one readonly, one =
> read-write. Those who really want 3+ layers can use stack Overlayfs =
> multiple times: yes it'd be less efficient, but so what? First we want =
I don't think consuming stack space is efficiency issue.
> We all have to accept a solution that's pretty good NOW but less than =
> perfect. Otherwise we'll continue to have these debates and discussions =
> for years on end.
If you think merging overlayfs means the end of discussion, then I won't
agree. It may be a beginning.
J. R. Okajima
next prev parent reply other threads:[~2011-06-16 23:41 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-01 12:46 [PATCH 0/7] overlay filesystem: request for inclusion Miklos Szeredi
2011-06-01 12:46 ` [PATCH 1/7] vfs: add i_op->open() Miklos Szeredi
2011-06-01 12:46 ` [PATCH 2/7] vfs: export do_splice_direct() to modules Miklos Szeredi
2011-06-01 12:46 ` [PATCH 3/7] vfs: introduce clone_private_mount() Miklos Szeredi
2011-06-01 12:46 ` [PATCH 4/7] overlay filesystem Miklos Szeredi
2011-06-01 12:46 ` [PATCH 5/7] overlayfs: add statfs support Miklos Szeredi
2011-06-01 12:46 ` [PATCH 6/7] overlayfs: implement show_options Miklos Szeredi
2011-06-01 12:46 ` [PATCH 7/7] overlay: overlay filesystem documentation Miklos Szeredi
2011-06-08 22:32 ` [PATCH 0/7] overlay filesystem: request for inclusion Andrew Morton
2011-06-09 1:59 ` NeilBrown
2011-06-09 3:52 ` Andrew Morton
2011-06-09 12:47 ` Miklos Szeredi
2011-06-09 19:38 ` Andrew Morton
2011-06-09 19:49 ` Felix Fietkau
2011-06-09 22:02 ` Miklos Szeredi
2011-06-10 3:48 ` J. R. Okajima
2011-06-10 9:31 ` Francis Moreau
2011-06-16 18:27 ` Ric Wheeler
2011-06-10 10:19 ` Michal Suchanek
2011-06-12 7:44 ` J. R. Okajima
2011-06-13 18:48 ` Miklos Szeredi
2011-07-08 14:44 ` Miklos Szeredi
2011-07-08 15:21 ` Tomas M
2011-07-09 12:22 ` J. R. Okajima
2011-07-15 12:33 ` Miklos Szeredi
2011-07-15 13:02 ` J. R. Okajima
2011-07-15 13:04 ` J. R. Okajima
2011-07-15 13:07 ` Miklos Szeredi
2011-07-15 13:33 ` J. R. Okajima
2011-07-15 15:16 ` Miklos Szeredi
2011-06-09 13:49 ` Andy Whitcroft
2011-06-09 19:32 ` Andrew Morton
2011-06-09 19:40 ` Linus Torvalds
2011-06-09 20:17 ` Miklos Szeredi
2011-06-09 22:58 ` Anton Altaparmakov
2011-06-11 2:39 ` Greg KH
2011-06-12 20:51 ` Anton Altaparmakov
2011-06-10 11:51 ` Bernd Schubert
2011-06-10 12:45 ` Michal Suchanek
2011-06-10 12:54 ` Bernd Schubert
2011-06-09 13:57 ` Michal Suchanek
2011-06-09 13:57 ` Andy Whitcroft
2011-07-05 19:54 ` Hans-Peter Jansen
2011-07-08 12:57 ` Miklos Szeredi
2011-07-10 8:23 ` Ric Wheeler
2011-07-10 13:55 ` Sorin Faibish
2011-07-12 15:59 ` Miklos Szeredi
2011-07-10 11:16 ` Hans-Peter Jansen
2011-07-12 16:15 ` Miklos Szeredi
[not found] ` <4540f7aa16724111bd792a1d577261c2@HUBCAS1.cs.stonybrook.edu>
2011-06-16 6:51 ` Erez Zadok
2011-06-16 9:45 ` Michal Suchanek
2011-06-16 10:45 ` Jordi Pujol
2011-06-16 15:15 ` J. R. Okajima
2011-06-16 16:09 ` Miklos Szeredi
2011-06-16 22:59 ` J. R. Okajima
2011-07-08 14:40 ` Miklos Szeredi
2011-07-09 12:18 ` J. R. Okajima
2011-07-15 10:59 ` Miklos Szeredi
[not found] ` <b624059d70d546d4a4ecb940613235ab@HUBCAS2.cs.stonybrook.edu>
[not found] ` <BF42D8D9-B947-448A-8818-BCA786E75325@fsl.cs.sunysb.edu>
2011-06-16 23:41 ` J. R. Okajima [this message]
[not found] ` <ab75a25c918145569b721dea9aea5506@HUBCAS2.cs.stonybrook.edu>
[not found] ` <BF19F4F8-9E0F-4983-87C1-BB1B0A11D011@fsl.cs.sunysb.edu>
2011-06-17 1:49 ` J. R. Okajima
[not found] <20110609125114.8dff08da.akpm@linux-foundation.org>
2011-06-10 6:57 ` Fw: " Valerie Aurora
2011-06-10 9:01 ` Alan Cox
2011-06-15 11:19 ` Miklos Szeredi
2011-06-15 14:32 ` J. R. Okajima
2011-06-15 15:49 ` Miklos Szeredi
2011-06-15 16:14 ` J. R. Okajima
2011-06-15 17:20 ` Michal Suchanek
2011-06-15 18:12 ` Miklos Szeredi
2011-06-16 2:43 ` J. R. Okajima
2011-06-16 10:35 ` Michal Suchanek
2011-06-16 15:15 ` J. R. Okajima
2011-06-17 7:38 ` Michal Suchanek
2011-06-20 0:43 ` J. R. Okajima
[not found] ` <803fd88dc28748428861b75afdee3575@HUBCAS1.cs.stonybrook.edu>
2011-06-16 0:44 ` Erez Zadok
2011-06-16 3:07 ` J. R. Okajima
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=15841.1308267663@jrobl \
--to=hooanon05@yahoo.co.jp \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=ezk@fsl.cs.sunysb.edu \
--cc=hramrach@centrum.cz \
--cc=jordipujolp@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mszeredi@suse.cz \
--cc=nbd@openwrt.org \
--cc=neilb@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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).