linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: unionfs
Date: Tue, 16 Mar 2004 18:10:38 +0100	[thread overview]
Message-ID: <20040316171038.GA27046@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <200403161618.i2GGITKK004831@eeyore.valparaiso.cl>

On Tue, 16 March 2004 12:18:29 -0400, Horst von Brand wrote:
> =?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de> said:
> > Horst von Brand <vonbrand@inf.utfsm.cl> said:
> 
> > What looks like a promising idea for this problem and others is to
> > have visible and invisible inodes.  All current filesystems know only
> > visible inodes.  Invisible ones have no dentry linking to them
> > directly, only indirectly through files/links with cow semantics.
> 
> But this is then _one_ filesystem, not a stack of them added/deleted in
> random order while running. _So_ it is easy... and mostly useless.

Maybe.  I personally don't care much about links between filesystems,
but some people seem to, so there should be some use.

BTW: Why would you want to mount/umount filesystems in a stack in
random order?

> > Yeah, maybe.  My personal consensus right now is that this actually
> > looks very simple.  Not sure how much time I will find, but it should
> > definitely be finished for 2.8.
> 
> As I said: Not too hard, doable. But not sensibly. And needs to mess with
> _all_ filesystems (on disk and kernel guts) if they want to someday perhaps
> somewhere participate...  Besides, the people asking for this mostly really
> want version control, or get what they want from symlink farms.

So what?  Yes, I have to tweak vfs, but mainly to save tons of memory.
Cannot imagine too many complaints against that.  All filesystems that
want stacking capability have to be changed, the rest can set a couple
of pointers to NULL.  Effectively it will come down to ext[23], maybe
reiser and xfs plus those fifty special purpose filesystems that never
make it into linus' tree anyway.

And version control is something I actually want to be done inside the
kernel, at least to some degree.  People already use kernel support,
although it sucks (cp -lr anyone?).  Looks like the alternatives suck
even more, so your point is void.

Jörn

-- 
/* Keep these two variables together */
int bar;

  reply	other threads:[~2004-03-16 17:14 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-15 11:35 unionfs Carsten Otte
2004-03-15 12:19 ` unionfs Jörn Engel
2004-03-15 12:47   ` unionfs Ian Kent
2004-03-15 13:16     ` unionfs Jörn Engel
2004-03-15 14:35       ` unionfs Ian Kent
2004-03-15 16:13         ` unionfs Jörn Engel
2004-03-15 17:09           ` unionfs Claudio Martins
2004-03-15 19:22           ` unionfs Horst von Brand
2004-03-15 23:20             ` unionfs Chris Friesen
2004-03-16 16:04               ` unionfs Horst von Brand
2004-03-16 17:31                 ` unionfs Jörn Engel
2004-03-16 18:04                   ` unionfs Jörn Engel
2004-03-16 19:40                     ` unionfs Horst von Brand
2004-03-16 20:45                       ` unionfs Jörn Engel
2004-03-16 19:19                   ` unionfs Horst von Brand
2004-03-16 20:00                     ` unionfs Chris Friesen
2004-03-23  2:38                   ` unionfs Robert White
2004-03-15 23:52             ` unionfs Jörn Engel
2004-03-16 16:18               ` unionfs Horst von Brand
2004-03-16 17:10                 ` Jörn Engel [this message]
2004-03-19  9:11                   ` unionfs Jamie Lokier
2004-03-19  9:42                     ` unionfs Jörn Engel
2004-03-19  9:04                 ` unionfs Jamie Lokier
2004-03-16 19:03             ` unionfs Andy Isaacson
2004-03-15 14:37       ` unionfs Ian Kent
2004-03-15 16:15       ` unionfs Jörn Engel
  -- strict thread matches above, loose matches on Subject: below --
2004-03-08  9:52 unionfs Miklos Szeredi
2004-03-08 16:10 ` unionfs Bernd Schubert
2004-03-09  9:38   ` unionfs Miklos Szeredi
     [not found] ` <20040311151343.GA943@escher.cs.wm.edu>
2004-03-11 15:44   ` unionfs Miklos Szeredi
2004-03-14  2:33     ` unionfs Ian Kent
2004-03-14  4:20       ` unionfs Horst von Brand
2004-03-16 12:42       ` unionfs Miklos Szeredi
     [not found]     ` <20040315214207.GA26615@escher.cs.wm.edu>
2004-03-16 13:43       ` unionfs Miklos Szeredi
2004-03-12 23:37 ` unionfs Herbert Poetzl

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=20040316171038.GA27046@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vonbrand@inf.utfsm.cl \
    /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).