jwalther <firstname.lastname@example.org> 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
> 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
> > 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.