> We should keep in mind what problem we're trying to solve, though. The
> discussion was originally centered around trying to find a place to
> store the high 32 bits of i_size. I still think i_dir_acl is the best
> place to store this, although it's pending negotiations with Remy as to
> why he thinks non-directory inodes need to use the i_dir_acl field.
i havent seen this one mentioned: threre are 3 x 32 bits unused (unnamed)
OS-dependent fields. Does Hurd really use those fields?
> While we're on the subject of making changes to how the ext2 inode
> stores direct block pointers, the far more efficient change to make is
> to store extents (triples of starting logical block, starting physical
> block, number of blocks) in the inode. This works since most files use
> contiguously allocated blocks, so why not take advantage of that
> encoding efficiency.
doesnt this change the speed of bmap() from O(1) to O(log(N))? With the
current scheme we exactly know where to look to get the index, with
extents we have to binary-search every table? And, why do we have to store
both logical and physical blocks, is there any nontrivial translation
between them?
> The hard part is deciding when an inode's blocks should be encoded as
> extents, and when it should revert back to the old system. For files
> which are created with a lot of seeks and jumping around, it may be much
> more efficient to use the old scheme. Most of the time, though, we're
> much better off using the extent-based encoding system.
isnt there a problem with holes, plus we can not 'merge' extents? So this
seems to be a mostly creation-time decision. Holes have to be encoded as
single-block extents this way. (we do not know how fragmented a hole will
be when it gets allocated some time later)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu