lkml.org 
[lkml]   [1998]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -hpa
<BR>&nbsp;</UL>
Using gdbm means that you have two naming systems, one for objects
<BR>in gdbm, and one for objects in the file system.&nbsp; 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>&nbsp;

<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.&nbsp; 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.&nbsp; The architect
<BR>can provide a structural framework that has a marked impact on the
<BR>efficiency and utility of those interactions.&nbsp; 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.&nbsp; (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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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>&nbsp;</HTML>
\
 
 \ /
  Last update: 2005-03-22 13:44    [W:1.967 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site