Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

Hans Reiser wrote:
> Hubert Chan wrote:
>
>
> > On Tue, 05 Jul 2005 20:50:08 -0400 EDT, "Alexander G. M. Smith" <agmsmith@rogers.com> said:
> >
> >
> >
> >
> > > That sounds equivalent to no hard links (other than the usual parent
> > > directory one).  If there's any directory with two links to it, then
> > > there will be a cycle somewhere!
> > >   
> >
> > What we want is no directed cycles.  That is A is the parent of B is the
> > parent of C is the parent of A.  We don't care about A is the parent of
> > B is the parent of C; A is the parent of B is the parent of C.
> >
> > OK, here's a random idea that just popped into my head, and to which
> > I've given little thought (read: none whatsoever), and may be the
> > stupidest idea ever proposed on LKML, but thought I would just toss it
> > out to see if it could stimulate someone to come up with something
> > better (read: sane):  Conceptually, foo/.... is just a symlink to
> > /meta/[filesystem]/[inode of foo].
>
> Except that we want the metafiles to go away when the base file goes away.

Only, /meta is a filesystem that already makes stuff go away for us, so 
all we have left is the issue of whether using /meta costs us 
performance, or whether breaking POSIX to add a symlink (such as 
foo/...) really gives us that much more usability.

I don't know the first thing about whether it costs us performance, 
although it seems like it could be negligable considering the existance 
of mount --bind.

I don't think file-as-dir gives us that much more usability, because we 
can always create a simple program or shell script that 'cd's us into 
metadata.  It's still easier than having a simple program that 
manipulates the metadata directly, because this way we can do 'cd' and 
'ls' and so on inside the metadata directory.

And, once we start talking about applications, /meta will be more 
readily supported (as in, some apps will go through a pathname and stop 
when they get to a file, and then there's tar).  On apps which don't 
have direct support for /meta, you'd be navigating to the file in 
question and then manually typing '...' into the dialog, so I don't see 
why typing '...' at the end is better than typing '/meta' or '/meta/vfs' 
at the beginning.

That said, I'm still not entirely sure how we get /meta/vfs to work 
other than adding a '...' sort of delimiter anyway.

> > And a question: is it feasible to store, for each inode, its parent(s),
> > instead of just the hard link count?
>
> Ooh, now that is an interesting old idea I haven't considered in 20
> years.... makes fsck more robust too....

Doesn't it make directory operations slower, too?

And, will it require a format change?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/