Messages in this thread | | | Date | Mon, 2 Mar 1998 20:13:53 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Big files in ext2fs (but not i_osync) |
| |
Date: Mon, 2 Mar 1998 10:52:56 +0100 (CET) From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
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
| |