Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 18 Dec 2006 01:18:01 -0800 | From | Andrew Morton <> | Subject | Re: 2.6.19 file content corruption on ext3 |
| |
On Mon, 18 Dec 2006 18:22:42 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Andrew Morton wrote: > > On Mon, 18 Dec 2006 15:51:52 +1100 > > Nick Piggin <nickpiggin@yahoo.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). > > By saying that there shouldn't be any dirty ptes if there are no > dirty buffers? But in that case the _page_ shouldn't be dirty either, > so that clear_page_dirty would be redundant. But presumably it isn't.
I don't follow that.
The linkage between pte-dirtiness and buffer_heads is a bit hard to follow without also considering page-dirtiness.
> > 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. > > Yes I could believe it the corruption is caused by something else > completely.
Think so. We do have a problem here, but only on threaded apps, I believe. rtorrent doesn't appear to be threaded, and the bug is hit on non-preempt UP.
> >>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. > > After try_to_free_buffers detaches the buffers from the page, a > pagefault can come in, and mark the pte writeable, then set_page_dirty > (which finds no buffers, so only sets PG_dirty). > > The page can now get dirtied through this mapping. > > try_to_free_buffers then goes on to clean the page and ptes.
try_to_free_buffers() isn't called against a page which doesn't have buffers. It'll oops.
> Were you testing with preempt?
nope, just SMP.
- 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/
| ![\](/images/icornerr.gif) |