From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754939AbZHCN4s (ORCPT ); Mon, 3 Aug 2009 09:56:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754891AbZHCN4s (ORCPT ); Mon, 3 Aug 2009 09:56:48 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:52082 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754629AbZHCN4r (ORCPT ); Mon, 3 Aug 2009 09:56:47 -0400 Date: Mon, 3 Aug 2009 15:56:17 +0200 From: Ingo Molnar To: Chris Mason , Roland Dreier , Frederic Weisbecker , Andi Kleen , LKML , Jeff Mahoney , Alexander Beregalov , Bron Gondwana , Reiserfs , Al Viro , Andrea Gelmini , "Trenton D. Adams" , Thomas Meyer , Alessio Igor Bogani , Marcel Hilzinger , Edward Shishkin Subject: Re: [ANNOUNCE] Reiserfs/kill-bkl tree v2 Message-ID: <20090803135617.GB15020@elte.hu> References: <20090731174642.GA6539@nowhere> <20090801081141.GA18036@basil.fritz.box> <20090801155335.GA4836@nowhere> <20090802142100.GA21160@elte.hu> <20090803132659.GC3570@think> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090803132659.GC3570@think> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Chris Mason wrote: > Definitely, the cost of the rare bug is much higher. The good > news is that reiserfs tends to pile its races into a few spots. > Most of them can be found with a 12 hour run of the namesys > stress.sh program and a lot of memory pressure. I'd compile with > preemption on and you'll have a good test on any SMP machine. > > http://oss.oracle.com/~mason/stress.sh > > stress.sh just copies a source directory into the test filesystem, > then reads it back and deletes it in a loop. I'd run with 50 > procs and enough memory pressure for the box to lightly swap > (booting w/mem= is a fine way to make memory pressure). This way > you make sure to hammer on the metadata writeback paths, which is > where all of the difficult races come in. > > Testing with an fsx-linux process running at the same time will > make sure all of the mmap/truncate paths are working correctly as > well. Ok, that definitely looks like something feasible to run for Frederic too, thanks for the detailed suggestion! Ingo