> > I wouldn't waste time trying to make amazingly clever ext2fs extensions
> > playing with reserved/unused bits in the structures. My feeling is that
> > the direction should be ext3fs (based on ext2fs)
>
> While talking about ext3. I do not think it should be ext2 based. I do
> not like linear searching for files ext2 does. (I made directory with
> ~3000 files and it go slooooooooooooooooooooooowwwwww, much too slow.)
>
> And - we need files >4G on ext2 *now*. Mj's smugfs is solution for us,
> but other people probably would not like it, and it is _hack_.
I agree, ext2fs has some serious shortcomings performance wise if it were
moved to 64-bit. However, the scope of that project is much too large to
handle and be done in a reasonable amount of time. I believe that there is
an ext3fs project out and about right now (?) which is dealing with these
issues. Personally, I'd support making a clean 64-bit ext3fs based
directly off of ext2fs and moving the current ext3fs to ext4fs. The other
advantage is that making a working 64-bit fs now (slow or not) can get the
VFS layer 64-bit clean ASAP rather than waiting for a "better" 64-bit fs
implementation.
-Rob H.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu