lkml.org 
[lkml]   [2002]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: The reason to call it 3.0 is the desktop (was Re: [OT] 2.6 not 3.0 - (NUMA))
    Theodore Ts'o wrote:
    >
    > ...
    > It depends on what you are doing. BSD, and even XFS, uses the concept
    > of using cylinder groups or block groups as one of many tools to avoid
    > file fragmentation and to concetrate locality for files within a
    > directory. The reason why FAT filesystems have file fragmentation
    > problems in far more worse way is because they attempt don't have the
    > concept of a block group, and simply always allocate from the
    > beginning of the filesystem. This is effectively what would happen if
    > you had a single block/cylinder group in the filesystem.
    >

    In the testing which I did, based on Keith Smith's traces, the
    current code really isn't very effective.

    What I did was to run his aging workload an increasing number of
    times. Then measured the fragmentation of the files which it
    left behind. I measured the fragmentation simply by timing
    how long it took to read all the files, and compared that to
    how long it took to read the same files when they had been laid
    down on a fresh fs.

    After ten aging rounds, with the current block allocator, we're
    running 4x to 5x times slower. With the Orlov allocator, we're
    running 5x to 6x slower. Either way, that's a big performance
    slowdown.

    Orlov turns a 400% slowdown into a 500% slowdown. So it is a
    25% regression for slow growth. But it is a 300% to 500%
    improvement for fast-growth. (Well, it used to be. But I
    just fixed a memory-corrupting bug in it which I think has
    slowed it down. It's now only double the speed on scsi, triple
    on IDE).

    What we need, *regardless* of which allocator is used is effective
    defrag tools.

    I just retested.

    2.5.41, scsi:
    time find linux-2.4.19 -type f | xargs cat > /dev/null
    find linux-2.4.19 -type f 0.06s user 0.24s system 1% cpu 19.274 total
    xargs cat > /dev/null 0.23s user 1.42s system 8% cpu 19.954 total

    2.5.41, IDE:
    time find linux-2.4.19 -type f | xargs cat > /dev/null
    find linux-2.4.19 -type f 0.06s user 0.23s system 0% cpu 29.274 total
    xargs cat > /dev/null 0.23s user 1.58s system 5% cpu 30.199 total

    2.5.41+Orlov, SCSI:
    time find linux-2.4.19 -type f | xargs cat > /dev/null
    find linux-2.4.19 -type f 0.06s user 0.24s system 2% cpu 11.579 total
    xargs cat > /dev/null 0.23s user 1.46s system 14% cpu 11.951 total

    2.5.41+Orlov, IDE:
    time find linux-2.4.19 -type f | xargs cat > /dev/null
    find linux-2.4.19 -type f 0.06s user 0.24s system 2% cpu 12.225 total
    xargs cat > /dev/null 0.22s user 1.59s system 14% cpu 12.500 total

    We need some of that goodness.

    >
    > [ administrator hints ]
    >

    Alas, nobody uses them :(

    Maybe a mount option? But I think the current algorithm should
    default to "off".
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:29    [W:4.145 / U:0.648 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site