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