Messages in this thread | | | Date | Sat, 05 Sep 1998 02:13:11 -0700 | From | Hans Reiser <> | Subject | Re: (reiserfs) Re: Implementing Meta File information in Linux (and why not just use gdbm, or MIME, or Structured Storage) |
| |
<HTML>
<UL>For the small data objects (i.e. "resources"), it seems that using a <BR>standard database library like gdbm or db is appropriate.
<P> -hpa <BR> </UL> Using gdbm means that you have two naming systems, one for objects <BR>in gdbm, and one for objects in the file system. So why is this bad?.....
<P>I am going to give you my most abstract answer to this question, as <BR>extracted from the intro to an old paper I wrote. <BR>
<P>Why Is There A Move In OS Design Towards Unifying Name Spaces?
<P>An operating system is composed of components that access other <BR>components through interfaces. Operating systems are complex enough <BR>that, like national economies, the architect cannot centrally plan the <BR>interactions of the components that it is composed of. The architect <BR>can provide a structural framework that has a marked impact on the <BR>efficiency and utility of those interactions. A few simple principles <BR>may help convey some of the ways that impact can be achieved through <BR>name space design.
<P>If one increases the number of other components that a particular <BR>component can interact with, one increases its expressive power and <BR>thereby its utility. (Note that the very tempting to make statement <BR>that ``a component's expressive power is proportional to the number of <BR>other components it can be combined with'' was avoided, as it is <BR>unscientifically precise.)
<P>One can increase the number of other components that a particular <BR>component can interact with either by increasing the number of <BR>interfaces it has, or by increasing the number of components that are <BR>accessible by its current interfaces.
<P>Like the cost of wires dominates circuit design cost, the cost of <BR>component interfaces dominates software design cost.
<P>Name spaces such as the file system are used as component interfaces <BR>much like buses are used in circuit design.
<P>These three principles together imply that if one designs one operating <BR>system to have ten different name spaces but with twice as many <BR>components as another operating system with a single unified name space, <BR>unless one pays the prohibitive cost of implementing an interface to all <BR>ten of the name spaces for every component it is entirely possible and <BR>even likely that the operating system with half the components (and half <BR>the implementation cost) will have substantially more expressive power <BR>and utility. That is an enormous motivation, and this motivation has <BR>moved a number of OS researchers in their work. [e.g. Pike ``The Use of <BR>Name Spaces in Plan9'' and ``The Hideous Name'' <BR><A HREF="http://magnum.cooper.edu:9000/~rp/html/rob.html">http://magnum.cooper.edu:9000/~rp/html/rob.html</A> and <BR><A HREF="http://www-psrg.lcs.mit.edu/Projects/SFS/newsfs.ps">http://www-psrg.lcs.mit.edu/Projects/SFS/newsfs.ps</A>]
<P>Unfortunately, it is not a small technical effort to combine name <BR>spaces. To combine 10 name spaces requires, if not the effort to create <BR>10 name spaces, perhaps an effort equivalent to creating 5 of the name <BR>spaces. Usually each of the name spaces has particular performance and <BR>semantic power requirements that require enhancing the unified name <BR>space, and it usually requires technical innovation to combine the <BR>advantages of each of the separated name spaces into a unified name <BR>space. I would characterize none of the research groups currently <BR>approaching this unification problem as having funding equivalent to <BR>what went into creating 5 of the name spaces they would like to unify, <BR>and we are certainly no exception. For this reason we have picked one <BR>particular aspect of this larger problem for our focus: allowing small <BR>objects to effectively share the same file system interface that large <BR>objects use currently. <BR> </HTML>
| |