>> 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