An Idea that I've been toying with, but only spent minimal effort on
to day involves a new FS idea, at least for Linux How bout an ODBFS?
My argument looks something like this. What does a modern FS try to
do? Manage large collections of data as efficiently as possible allow for
fine grained locking, fast indexing, solid network support and possible extras
like compression and versioning. DB people solved these problems years ago.
With an object database relations are calculated at insertion and
update, this can be done with the equivalent of directory entries and should
help keeps things fast. We can allow ACL's based on object type that can be
adjusted over the life of the system(I don't know how expandable POSIX.6
(100-something now) is, but this is far more modifiable.
Things that make a FS work well, like fine grained locking and solid
interfaces to mmap are all doable. Network API, including CORBA interfaces
are cropping up in the new generation of ORDBs. Which brings up an important
point. We could guarantee a consistent OO interface to object in the ODBFS.
Each object could describe itself when inquired about, basic meta-info current
file-systems maintain, like size, but also things that could spare us some of
the hassle like file type, skipping over things like /etc/magic.
Sure this would break a lot of tools and its not a standard wide use
FS, but if anyone has a positive initial response to the idea I'd love to hear
about it. If people anyone want to hear more, I can explain how it ties into
the neural-fuzzy scheduler to record scheduling information about each object
and caching object memory usage for a slab allocator to pre-alloc object based
on usage, but I digress. ;>
-- Benjamin Saller Bender <case@AppliedTheory.com> AppliedTheory Communications Software Engineering Group http://AppliedTheory.com/ Sentio aliquos togatos contra me conspirare.