[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20061217214308.62b9021a.akpm@osdl.org>
Date: Sun, 17 Dec 2006 21:43:08 -0800
From: Andrew Morton <akpm@...l.org>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Linus Torvalds <torvalds@...l.org>, andrei.popa@...eo.ro,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Hugh Dickins <hugh@...itas.com>,
Florian Weimer <fw@...eb.enyo.de>,
Marc Haber <mh+linux-kernel@...schlus.de>,
Martin Michlmayr <tbm@...ius.com>
Subject: Re: 2.6.19 file content corruption on ext3
On Mon, 18 Dec 2006 15:51:52 +1100
Nick Piggin <nickpiggin@...oo.com.au> wrote:
> I think the problem Andrew identified is real.
I don't. In fact I don't think I described any problem (well, I tried to,
but then I contradicted myself).
Six hours here of fsx-linux plus high memory pressure on SMP on 1k
blocksize ext3, mainline. Zero failures. It's unlikely that this testing
would pass, yet people running normal workloads are able to easily trigger
failures. I suspect we're looking in the wrong place.
> The issue is the disconnect between the pte dirtiness and a filesystem
> bringing buffers clean.
Really? The dirtying direction goes pte_dirty->PG_dirty->BH_Dirty and the
cleaning direction goes !BH_Dirty->!PG_dirty->!pte_dirty. That's pretty
simple, setting aside races.
In the try_to_free_buffers case there's a large time inverval between
!BH_Dirty and !PG_dirty, but that shouldn't affect anything.
I don't think we even have a theory as to what's gone wrong yet.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists