i havent seen this one mentioned: threre are 3 x 32 bits unused (unnamed)
OS-dependent fields. Does Hurd really use those fields?
Yes, the Hurd really does use those fields, and some of them we might
want to use for similar reasons (i.e., to support 32-bit uids, for
example).
> 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?
Well, you only use extent encoding in places where it's a real win. For
example, a quick check with e2fsck will show you that a large percentage
of files (on my system, close to 95%) are contiguous, and so would only
need a *single* extent. Log(N) where N is small is not a problem; in
fact, if you can keep the extents stored in the inode, it'll be faster
since you won't have to consult as many indirect blocks.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu