[lkml]   [1998]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Big files in ext2fs (but not i_osync)
       Date: Mon, 2 Mar 1998 10:52:56 +0100 (CET)
    From: MOLNAR Ingo <>

    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

    > 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

     \ /
      Last update: 2005-03-22 13:41    [W:0.018 / U:4.608 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site