Messages in this thread | | | Subject | Re: Ext2fs and hashed table. | From | (Stephen C. Tweedie) | Date | 01 Jun 1997 10:14:36 +0100 |
| |
Hi all,
jwalther <jwalther@citytel.net> writes:
> How about we just get that undelete flag doing something useful in ext2 > first before we think about ext3, eh? ext2 *still* isnt finished. Ted, > c'mon man, we need you doing ext2, cant libc wait a bit?
Don't worry, ext2 is still under active development. Watch this space...
> On Fri, 30 May 1997, Bas Mevissen wrote: > > Maybe it is just time to write ext3, with the following features: > > 64 bit architecture > an easy couple weeks work for someone who has access to a 64 bit machine
> > very long files (gigabytes) (for dbases) > already done I thought?
Not already done, but ext2fs will certainly support 64-bit file sizes soon. The hard work is in making a new, 64-bit API for 32-bit machines --- that's mostly a syscall and library problem, not a filesystem problem.
> > compression > patches already exist
Hope to have it integrated for 2.2.
> > raid support > supported in kernel....
> > fast directory searching (by hashing of course) > no way. b-trees are the *right* way to do it.
No, b-trees are the *WRONG* way to do it, big time. Except for *very* large directories, tens or hundreds of thousands of entries. b-trees have got far too much overhead for 99.99% of cases. Hash tables work a lot better, and there are schemes for dynamically sizing the hash table which give most of the scalability of b-tree lookup.
Cheers, Stephen.
| |