[lkml]   [2001]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Ext2-devel] disk throughput

    On Mon, Nov 05, 2001 at 02:22:41PM -0800, Andrew Morton wrote:

    > For some workloads we want the subdirectories close to the
    > parent as well. Failing to do so is horridly wrong.

    If you apply that recursively, then _all_ the directories in a
    filesystem end up in the same place. ext2 has traditionally been
    extremely resistant to fragmentation degradation over time, and the
    spreading out of the directory tree over the filesystem is part of

    > What has changed since Kirk's design?
    > - The relative cost of seeks has increased. Device caching
    > and readahead and increased bandwidth make it more expensive
    > to seek away.

    I'm not convinced about that. Modern disks are so fast at streaming
    that _any_ non-sequential access is a major cost. Track-to-track
    seeks are typically well under the average rotational cost. It's not
    seeking to a distant location that's particularly expensive: any seek
    is, whether to the the same track or not.

    > I don't think I buy the fragmentation argument, really.

    Recent experiments showed that reiserfs, which starts off allocating
    files quite close together, was significantly faster than ext2 on
    mostly-empty filesystems but got hugely slower as you approached 90%
    full or more. I don't buy the argument that you can ignore
    fragmentation. There must be a balance between short-term performance
    when allocating files and long-term performance when ensuring you've
    got enough free space inside a directory tree to cope with new files.

    Even kernel builds may show this up. If you try to keep a directory
    tree compact, then you may get excellent performance when unpacking
    the kernel tarball. But once you've applied a few large patch sets
    and set the kernel build going, your new files, .c.orig patch backups,
    and .o files will have nowhere nearby to get allocated in.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:12    [W:0.024 / U:5.340 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site