Messages in this thread | | | Date | Mon, 31 Aug 1998 15:08:34 -0700 | From | Hans Reiser <> | Subject | Re: Implementing Meta File information in Linux |
| |
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
| |