lkml.org 
[lkml]   [1998]   [Mar]   [2]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 2 Mar 1998 22:13:23 -0500 (EST)
From"Albert D. Cahalan" <>
SubjectRe: Big files in ext2fs (but not i_osync)
Stephen C. Tweedie writes:

>> I thought that for a few days at first -- shall I support HOLES ?
>> I decided NOT TO DO SO IN THE EXTENT-CODED I-NODES.
>
> 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
calculation.

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 majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008