Re: reiser4 plugins

[David Masover]

Hans Reiser wrote:
> David Masover wrote:
>
>
> > 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.
>
>
> Performance.  If you type it at the end, and you already have done the
> lookup of the filename, then you can go from the file to one of its
> methods, instead of a complete new traversal of another tree under /meta

Only, it's a different view of the same tree.  That may not matter 
performance-wise, though.

Also, for performance-critical applications, the /meta tree is pretty 
easy -- it becomes more like /meta/inode/some_inode_number/.

There's also the chroot issue, though.

> > 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?
>
>
> Not sure.  It consumes space though.
>
>
> > And, will it require a format change?
>
> Yes, but we have plugins now, so.....

So, will the format change happen at mount time?  Will it need a special 
mount flag?  Will I need to use debugfs or some other offline tool?


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