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)
It would only take someone with the balls to get things going and the
already known linux-gurus to give their input so that ext3fs gets
designed in a way that allows future enhancements without noticeable
performance degradation.
There has been general enthusiasm for a "new" filesystem, but not
necessarily consensus on what the new features should contain.
For example, just to take the simplest example: when people say that
they want 64 bit support, do they mean:
* support for sparse files greater than 2GB?
* support for files which contain greater than 2**42 bytes of data
* support for large files that can be mmap'ed, or just read?
The requirements for all of these are different, and satisfying some of
them will have tradeoffs in such things as performance for the common
case (where the common case is *still* files less than 2GB). For
example, support for 64-bit non-sparse files on i386 machines will
require VM changes which Linus has already said he's not willing to
make, because of the performance hit you would take in needing to
manipulate 64-bit VM addresses everywhere.
Also, in general, compatibility with ext2 isn't the problem. We have
the right tools in the superblock to make this as painless as possible.
The hard part is actually *coding* the new features in such a way that
they are robust, maintainable, and efficient.
For example, if someone wants to design a new B-tree based directory
format, and gives me kernel and user-level routines for manipulating
them, it wouldn't at all difficult to add that into the existing ext2
filesystem. If necessary, we could even trivially set things up so that
old kernels could mount an ext2 filesystem read-write; it just wouldn't
be able to manipulate those directories which were using the new format.
The hard part is not in the compatibility; it's in writing the actual
B-tree directory code.
I could go on; there are also some very interesting designs on the board
for storing the block numbers attached to a file in a run length encoded
format, which is a big win for files which are contiguously stored on
disk, since it eliminates nearly all indirect blocks. Again, doing it
in a way which retains the basic ext2 filesystem format isn't the hard
part. It's actually providing support for the feature in the first place.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu