Re: unionfs

From: Jörn Engel
Date: Tue Mar 16 2004 - 12:17:58 EST


On Tue, 16 March 2004 12:18:29 -0400, Horst von Brand wrote:
> =?iso-8859-1?Q?J=F6rn?= Engel <joern@xxxxxxxxxxxxxxxxxxxx> said:
> > Horst von Brand <vonbrand@xxxxxxxxxxxx> 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;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/