From: Badari Pulavarty Subject: Re: [RFC][PATCH] set_page_buffer_dirty should skip unmapped buffers Date: Wed, 06 Sep 2006 20:04:27 -0700 Message-ID: <44FF8C3B.3040505@us.ibm.com> References: <1157128342.30578.14.camel@dyn9047017100.beaverton.ibm.com> <20060901101801.7845bca2.akpm@osdl.org> <1157472702.23501.12.camel@dyn9047017100.beaverton.ibm.com> <20060906124719.GA11868@atrey.karlin.mff.cuni.cz> <1157555559.23501.25.camel@dyn9047017100.beaverton.ibm.com> <20060906153449.GC18281@atrey.karlin.mff.cuni.cz> <1157559545.23501.30.camel@dyn9047017100.beaverton.ibm.com> <20060906162723.GA14345@atrey.karlin.mff.cuni.cz> <1157563016.23501.39.camel@dyn9047017100.beaverton.ibm.com> <20060906172733.GC14345@atrey.karlin.mff.cuni.cz> <20060906191430.7ffcd833.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kara , Anton Altaparmakov , sct@redhat.com, linux-fsdevel , lkml , ext4 Return-path: Received: from e5.ny.us.ibm.com ([32.97.182.145]:54233 "EHLO e5.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1030235AbWIGDEb (ORCPT ); Wed, 6 Sep 2006 23:04:31 -0400 To: Andrew Morton In-Reply-To: <20060906191430.7ffcd833.akpm@osdl.org> Sender: linux-ext4-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org Andrew Morton wrote: > On Wed, 6 Sep 2006 19:27:33 +0200 > Jan Kara wrote: > > >> Ugh! Are you sure? For this path the buffer must be attached (only) to >> the running transaction. But then how the commit code comes to it? >> Somebody would have to even manage to refile the buffer from the >> committing transaction to the running one while the buffer is in wbuf[]. >> Could you check whether someone does __journal_refile_buffer() on your >> marked buffers, please? Or whether we move buffer to BJ_Locked list in >> the write_out_data: loop? Thanks. >> > > The ext3-debug patch will help here. It records, within the bh, the inputs > from the last 32 BUFFER_TRACE()s which were run against this bh. If a > J_ASSERT fails then you get a nice trace of the last 32 "things" which > happened to this bh, including the bh's state at that transition. It > basically tells you everything you need to know to find the bug. > > It's worth spending the time to become familiar with it - I used it a lot in > early ext3 development. > I will try the patch. Unfortunately, adding more debug is causing the problem reproduction difficult. > I've been unable to reproduce this crash, btw. Is there some magic > incantation apat from running `fsx-linux'? > All I do is on a single 1k filesystem, run 4 copies of fsx (on 4 different files, ofcourse). I hit the assert anywhere between 10min-2hours. Thanks, Badari