lkml.org 
[lkml]   [2001]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Ext2-devel] disk throughput
    Hi,

    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
    that.

    > 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.

    Cheers,
    Stephen
    -
    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:12    [W:0.026 / U:177.668 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site