From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 11 Mar 2003 16:50:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 11 Mar 2003 16:50:52 -0500 Received: from tmr-02.dsl.thebiz.net ([216.238.38.204]:34316 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id ; Tue, 11 Mar 2003 16:50:52 -0500 Date: Tue, 11 Mar 2003 16:57:22 -0500 (EST) From: Bill Davidsen To: Alex Tomas cc: linux-kernel , ext2-devel@lists.sourceforge.net Subject: Re: [Bug 417] New: htree much slower than regular ext3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 7 Mar 2003, Alex Tomas wrote: > The problem is that getdents(2) returns inodes out of order and > du causes many head seeks. I tried to solve the problem by patch > I included in. The idea of the patch is pretty simple: just try > to sort dentries by inode number in readdir(). It works because > inodes sits at fixed places in ext2/ext3. Please, look at results > I just got: Any change in the order of dentries returned is likely to run into problem when seeking in a directory. Given that readdir() is usully followed by either zero or many stat()s, perhaps when the first stat() comes along you could pre-read the inodes in optimal order and cace them. However you tuned the size of your sort should work exactly as well as the size of the pre-read. This seems consistent with readahead and AS disk io. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.