[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110307190040.GI1873@nowhere>
Date: Mon, 7 Mar 2011 20:00:45 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Bastien ROUCARIES <roucaries.bastien@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Reiserfs deadlock in 2.6.36
Hi Bastien,
Sorry for the time I've been away.
On Sun, Jan 30, 2011 at 01:08:29AM +0100, Bastien ROUCARIES wrote:
> Le jeudi 23 décembre 2010 04:42:33, Frederic Weisbecker a écrit :
> Hi,
>
> I take me more than two days of testing to reporduce this bugs with trace enabled. My filesystem was quite slow and this bugs seems
> to be timing related.
>
> One patern that trigger this bug is git. Doing a lot of git work of my desktop crash my machine.
>
> Moreover, trying to reproduce this bug lead to data loss. I have rebuilded twice my / partition using --rebuild-tree, and restored
> my home partition three times using backups.
>
> My log is here.
>
> Do you need more information?
Yeah do you have CONFIG_REISERFS_CHECK? I just would
like to ensure we are not missing this important source of
information.
I'm puzzled because, given the traces, your opening and closing of the journal are
well balanced.
You have a writer queued and stuck but I see no trace of it in the traces stream.
I only see well balanced journal operations, including journal closing that would have
woken your queued writer.
A theory could be that your queued writer was waiting for someone to close the journal,
which finally happen but actually several minutes later, after there was many
journal opening/closing that overwrote the old trace containing the queueing of
the stuck writer.
I don't know what to do yet. I need to think more about it.
--
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