From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [ANNOUNCE] new new aops patchset Date: Wed, 4 Apr 2007 04:37:12 +0200 Message-ID: <20070404023712.GC18507@wotan.suse.de> References: <20070402120934.GA19626@wotan.suse.de> <1175558450.24533.22.camel@dyn9047017100.beaverton.ibm.com> <20070403000853.GF12295@wotan.suse.de> <20070403093117.GA7747@wotan.suse.de> <1175616230.24533.37.camel@dyn9047017100.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mcao@us.ibm.com, Linux Filesystems , Mark Fasheh , Steven Whitehouse To: Badari Pulavarty Return-path: Received: from mx2.suse.de ([195.135.220.15]:39346 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966300AbXDDChV (ORCPT ); Tue, 3 Apr 2007 22:37:21 -0400 Content-Disposition: inline In-Reply-To: <1175616230.24533.37.camel@dyn9047017100.beaverton.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Apr 03, 2007 at 09:03:50AM -0700, Badari Pulavarty wrote: > On Tue, 2007-04-03 at 11:31 +0200, Nick Piggin wrote: > > On Tue, Apr 03, 2007 at 02:08:53AM +0200, Nick Piggin wrote: > > > > BTW, I will take a shot at ext4 tomorrow. > > > > > > Thanks, so long as you think ext3 is looking OK? > > > > > > BTW. is it a known issue that ext3 fails fsx-linux? (I tried 2.6.21-rc3 > > > IIRC, and ordered and writeback both eventually failed I think). ext2 > > > does not. > > > > Well I just tested, and it is not fixed by the recent patch to revert > > ext3_prepare_failure.... > > > > Is this a known issue? Is it an fsx-linux shortcoming? It is fairly > > surprising because it basically makes it impossible to test ext3 > > changes with that nice tool :( I can submit the traces if anyone is > > interested, however I can reproduce in UML on an ext3 writeback > > filesystem with no arguments (except the filename). > > > > I haven't seen an fsx failure recently. I ran 4 copies of fsx > on 2.6.21-rc5 and 2.6.21-rc5+aops, without any problems for > 12+ hours. What am I missing ? Well this is in UML and mounted on loopback, so it could be a failure in the driver stack somewhere. However ext2 is completely solid, so I did suspect ext3. In my configuration, some IO operations that would take a reasonable amount of time on a real system will complete much more quickly. There might be an issue there? Using a ramdisk or loop over tmpfs might produce something. I'll ping you again if I can reproduce outside of UML.