Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 6 Nov 2001 17:23:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 6 Nov 2001 17:23:10 -0500 Received: from nat-pool-meridian.redhat.com ([199.183.24.200]:48708 "EHLO devserv.devel.redhat.com") by vger.kernel.org with ESMTP id ; Tue, 6 Nov 2001 17:22:57 -0500 Date: Tue, 6 Nov 2001 21:45:56 +0000 From: Stephen Tweedie To: Andrew Morton Cc: Alexander Viro , "Albert D. Cahalan" , Mike Fedyk , lkml , ext2-devel@lists.sourceforge.net Subject: Re: [Ext2-devel] disk throughput Message-ID: <20011106214556.M4137@redhat.com> In-Reply-To: <3BE647F4.AD576FF2@zip.com.au> <3BE71131.59BA0CFC@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE71131.59BA0CFC@zip.com.au>; from akpm@zip.com.au on Mon, Nov 05, 2001 at 02:22:41PM -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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/