Re: Implementing Meta File information in Linux

Hans Reiser (reiser@idiom.com)
Mon, 31 Aug 1998 15:08:34 -0700


Stephen C. Tweedie wrote:

> Hi,
>
> On Fri, 28 Aug 1998 03:47:49 -0700, Hans Reiser <reiser@idiom.com> said:
>
> > Stephen C. Tweedie wrote:
> >> I'd add here that in fact, reiserfs is a good reason NOT to implement
> >> metadata. By making it so much more efficient to store
> >> metainformation through hidden subdirectories, reiserfs allows the
> >> whole thing to be implemented in user space. That by itself is a good
> >> reason for not doing it in the kernel!
>
> > I was going to respond to this, but then I realized I didn't have a
> > solid definition of the desired semantics, which I would need before I
> > could intelligently respond to the issue of whether namei() should be
> > altered in its functionality.
>
> Personally, I think it is crazy to think about changing such a
> fundamental Unix concept as namei(). Multiple file forks are a great
> idea in principle, but Linux is not a research operating system: it is a
> Unix-like system.
>
> At the heart of the Unix philosophy is the principle of having lots of
> tools which can be combined together by the user in different ways. If
> we start to change our definition of what a "file" is, then the bulk of
> our existing tools will fail.
>
> That's not to say that we should never contemplate such a change.
> Indeed, Linux already has done so: the Linux file attributes (immutable,
> nodump, append-only etc) are information about a file which have no
> standard Unix counterparts.
>
> However, I think we can only justify such a thing in namei() if there is
> a compelling reason to have the new feature in the kernel. For a number
> of pending projects, such as file ACLs, we _do_ need to have the feature
> in the kernel: file permissions security simply has to be done in kernel
> space, not in user space. This argument does not hold for GUI-style
> forks to hold icons and so on. Directories can do that quite happily,
> without throwing out compatibility with a world of existing Unix tools.
>
> --Stephen

With regards to namei() in general:

I think that what you are failing to realize is that it is possible to change
namei() while retaining upward compatibility.

I have a complete set of semantics designed for namei() which are based
on what russians would call set-theoretic database theory. These semantics
give you everything that a keyword system or a database can give you but with
greater generality and abstraction. As a for instance, instead of keywords you
have key objects. Instead of unordered sets of ordered pairs (tuples) you have
ordered and unordered sets. Ordered sets can be traversed using /, as in /A/B/C/D.
In other words, you can keep Unix compatibility without encumbering the new
semantics. I wish to note that I have no intention of moving anywhere with this
for a good two years, as I want to stabilize reiserfs at its current task of
providing conventional semantics efficiently. It is because databases need to
be efficient at small objects that reiserfs is designed to be efficient at small objects;
it is necessary to the long term vision that we first addressed the small object
issue.

With regards to this problem in specific:

I gather that the problem being considered is how to store icons for files? Is that
the definition of the problem? Is the solution being considered whether to allow an object to be
both a directory and a file at the same time, so that the icon for the file can be stored
inside the directory that is the file? This solution would have other advantages for other
purposes than the icon problem.....

Hans

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html