Messages in this thread | | | Date | Thu, 26 Mar 1998 17:47:49 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: 1GB limit - new filesystem or ext3? |
| |
Date: Thu, 26 Mar 1998 09:45:46 -0500 (EST) From: Mark Lehrer <edge@dux.raex.com>
I have read about efforts to get larger files & more efficient large filesystems on Linux for years.
Is there one that is ready to be used or do we need to work on ext3?
ext2 has been the default filesystem for awhile but maybe it's time for another...
I've said this before on linux-kernel (and my apologies to those who are tired of hearing me say it), but earlier this week, I submitted ext2 patches to Linus to support > 2GB files (hereafter referred to as "large files") against 2.1.90. (Thanks to Jakub Jelinek for providing the initial version of those patches.)
Other efforts which are currently in design phase (I prefer to do careful design before blindly starting to code) include using a B-tree data structure for directories, and using a B-tree data structure to store block extents (something which Stephen is interested in).
There are other folks who are working on an alternative filesystem, such as reiserfs. I wish them well, and they certainly help keep those of us who do ext2 development honest. (Competition is good that way.) Still, I suspect people will find that it's not that simple to write a fast, reliable, and *robust* filesystem. If each of the people who say, "let's write a new filesystem", actually followed through on their initial enthusiasm and actually had a completed (or even half-completed) filesystem, we'd have hundreds if not thousands of filesystems by now. :-)
Work on the ext2 filesystem is not standing still, though. For example, the e2compr work *is* happening, and will eventually get folded into the mainline kernel (although perhaps not in time for 2.2).
If people want to help out, I could use some well-written, B-tree mangement routines that can handle insertions, deletions, splits, etc. in a multiprocessing environment. The plan that I (with discussions with Stephen) have been kicking around involves having a generic framework which handles the B-tree leaf management, so that we can reuse the B-tree routines for multiple purposes. If we set up the abstractions and the data formats correctly, it should be possible to initially use some very simple-minded B-tree routines, and then later replace them with more sophisticated one. The data abstractions should also hopefully allow us to set up a user-mode test framework where we can benchmark and test various candidate B-tree routines. I'm still very much in the initial stages of planning this, but some vague outlines are starting to take shape.
(Thanks to Stephen Tweedie and Colin Plumb who have been quite helpful in private discussions, especially in showing me the flaws in various straw-men proposals.)
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |