From: Neil Brown <neilb@suse.de>
To: noah <noah123@gmail.com>
Date: Tue, 23 Jan 2007 08:01:20 +1100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17845.9760.806387.670182@notabene.brown>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Bug in drivers/md/md.c ?
In-Reply-To: message from noah on Tuesday January 16
References: <d00698fb0701160013w53d13a4eo6e22ff658fb460bb@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1807
Lines: 52

On Tuesday January 16, noah123@gmail.com wrote:
> Hi!
> 
> I'm getting "md: bug in file drivers/md/md.c, line 1652" (see below) after
> writing data to a md-device using dd.
> Is it really a bug or am I just using mdadm in the wrong way? I'm unsure
> about the --assume-clean flag when creating the raid5 volume.

It is a bug, not an incorrect usage.

This patch (against 2.6.19-rcX) should fix it.

Thanks,
NeilBrown


Make sure the events count in an md array never returns to zero.

Now that we sometimes step the array events count backwards
(when transitioning dirty->clean where nothing else interesting
has happened - so that we don't need to write to spares all the time),
it is possible for the event count to return to zero, which is
potentially confusing and triggers and MD_BUG.

We could possibly remove the MD_BUG, but is just as easy, and
probably safer, to make sure we never return to zero.

Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./drivers/md/md.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c	2007-01-22 09:08:17.000000000 +1100
+++ ./drivers/md/md.c	2007-01-23 07:53:32.000000000 +1100
@@ -1633,7 +1633,8 @@ repeat:
 	 * and 'events' is odd, we can roll back to the previous clean state */
 	if (nospares
 	    && (mddev->in_sync && mddev->recovery_cp == MaxSector)
-	    && (mddev->events & 1))
+	    && (mddev->events & 1)
+	    && mddev->events != 1)
 		mddev->events--;
 	else {
 		/* otherwise we have to go forward and ... */
-
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/