Re: Big files in ext2fs (but not i_osync)

Albert D. Cahalan (
Mon, 2 Mar 1998 22:13:23 -0500 (EST)

Stephen C. Tweedie writes:

>> I thought that for a few days at first -- shall I support HOLES ?
> Holes are pretty much a non-problem if we code the extent map as a
> btree of (offset, extent) entries. Btree coding is already something
> we really ought to implement for the directory case, and this would be
> just a different type of key; we could reuse most of the btree code
> between the two.
> The btree approach has the advantage that sparse files of _any_ size
> can be coded very efficiently, with no more levels in the indirection
> tree than are needed for the number of extents actually used. There
> is no tree size dependency on the size of the file offsets as there is
> for static indirection trees.

That sounds nice. It doesn't sound like the ext2 filesystem though.
I wonder if there is a point at which the name "ext2" is just wrong.

Less complicated:
Because of the block groups, fragments will always contain less
than 2**16 blocks. Correct? The 12 direct pointers are enough
space for 8 extents if you skip the file offset information.
The file offset information can be skipped since a linear search
through 8 extents is not too bad. The rest of the file can be
addressed using the traditional ext2 indirect block pointers by
adjusting the calculation a little bit. In-core inodes could
store the total count of direct/extent blocks to simplify the

For people that really need a full tree-based filesystem, Reiserfs
might be a better choice. Hans Reiser has almost completed the port
from 2.1.42 to 2.1.8x, with the elimination of the "leashes" horror.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to