Messages in this thread | | | Date | Mon, 31 Aug 1998 16:15:14 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: Implementing Meta File information in Linux |
| |
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
- 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
| |