lkml.org 
[lkml]   [1998]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.064 / U:1.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site