Messages in this thread | | | Subject | Re: Ext2fs and hashed table. | Date | Fri, 30 May 1997 09:58:22 -0400 | From | Benjamin Saller Bender <> |
| |
Bas Mevissen <mailto:sgm@stack.nl> writes: >Maybe it is just time to write ext3, with the following features: > 64 bit architecture > very long files (gigabytes) (for dbases) > compression > raid support > fast directory searching (by hashing of course) > dynamic inode allocation (in directory tree e.g.) > >Just an idea...
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.
| |