Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 5 Aug 2002 05:50:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 5 Aug 2002 05:50:47 -0400 Received: from angband.namesys.com ([212.16.7.85]:53200 "HELO angband.namesys.com") by vger.kernel.org with SMTP id ; Mon, 5 Aug 2002 05:50:46 -0400 Date: Mon, 5 Aug 2002 13:54:20 +0400 From: Oleg Drokin To: Roland Kuhn Cc: linux-kernel@vger.kernel.org Subject: Re: reiserfs blocks long on getdents64() during concurrent write Message-ID: <20020805135420.A30430@namesys.com> References: <20020805094429.A5897@namesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2403 Lines: 51 Hello! On Mon, Aug 05, 2002 at 11:22:49AM +0200, Roland Kuhn wrote: > BTW: was it directly clear for you for what the do_journal_begin_r() was > waiting? I'm not so familiar with fs coding, especially the locking... I'd say that it's waiting for journal lock that was captured by kupdated (or something like that) doing periodic write_super() calls, when it thinks memory is low. Our tests some time ago shown that once memory is lower than some value, write_super() "method" is called for every superblock that have "dirty" flag set. In reiserfs that flushes the journal, and while journal is being flushed, nobody can create new transactions obviously, and since ls changes directory's atime in normal case, it want to open new transaction. Unfortunatelly dirty flag for reiserfs gets set way to often than necessary, we have some patches that should help this (from Chris Mason). You can try these for yourself too, for example from here: ftp://ftp.suse.com/pub/people/mason/patches/data-logging/02-commit_super-8-relocation.diff.gz > > > this is to use a sync mount, and there I discovered something really > > > strange: 2.4.19 gives me about 17MB/s while 2.4.18-3 (RedHat) was creeping > > > slow with 10kB/s! > > 2.4.18-3 is particularly bad know for this exact problem (slow write speed), > > you should consider upgrading to at least 2.4.18-5 kernel from redhat updates. > > For me on plain 2.4.18 the problem is not visible that bad as for you. > > I.e. ls on a directory where I write this big file finishes in under > > half a second. > Do you use IDE or SCSI? It seems like the SCSI drivers can have up to I tested on IDE. > > You said 2.4.19 writes stuff faster for you, how about testing ls on that > > kernel? > The call trace was from 2.4.19, and the situation actually was much better Ah, I thought call trace was from 2.4.18-3. > than in the 2.4.18-3 case, where it took about 1 minute for ls to come > back. So you might try the patch I mentioned or you can mount with nodiratime mount option to prevent updqting of directory atimes, but having atimes still to be updated on regular files at the same time. Bye, Oleg - 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/