From: Kasper Dupont <48755289462761382922@expires.02.sep.2006.kasperd.net>
To: linux-raid@vger.kernel.org
Subject: Re: No syncing after crash. Is this a software raid bug?
Date: Wed, 1 Mar 2006 22:56:43 +0100 [thread overview]
Message-ID: <20060301215641.GA27042@hactar.lan> (raw)
In-Reply-To: <20060301124432.GA3591@hactar.lan>
> Why would you not be happy? resyncs in general are bad since they
> indicate your data is possibly out-of-sync and the resync itself
> consumes an enormous amount of resources
Of course reducing the amount of resources spend on syncing is
a good thing. But it shouldn't be done at the expense of less
reliability.
> This is a feature of new-ish md driver code that more aggressively marks
> the array as "clean" after writes
A bit too aggressive it seems. How can it end up being marked
clean when the two mirrors differ?
> The end result is that the array will most likely be "clean" in all
> circumstances even a crash, and you simply won't need to resync
Shouldn't it be unclean while an update is in progress? And if
it is how come I have been completely unable to trigger a resync
even when it was reset while disks were busy writing?
Here is the program I have used to verify if the two mirrors are
in sync: http://kasperd.net/~kasperd/raidtest.c
This program find that there is a difference between the two
mirrors.
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-03-01 21:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-01 12:44 No syncing after crash. Is this a software raid bug? Kasper Dupont
2006-03-01 13:58 ` Luca Berra
2006-03-01 16:24 ` Mike Hardy
2006-03-01 21:56 ` Kasper Dupont [this message]
2006-03-02 13:48 ` Mario 'BitKoenig' Holbe
2006-03-03 13:39 ` Heinz Mauelshagen
2006-03-03 14:30 ` Mario 'BitKoenig' Holbe
2006-03-03 22:26 ` Heinz Mauelshagen
2006-03-03 23:01 ` Mario 'BitKoenig' Holbe
2006-03-04 9:01 ` Heinz Mauelshagen
2006-03-04 10:10 ` Mario 'BitKoenig' Holbe
2006-03-03 7:30 ` Kasper Dupont
2006-03-03 12:03 ` Mario 'BitKoenig' Holbe
2006-03-03 12:38 ` Mario 'BitKoenig' Holbe
2006-03-03 14:48 ` Kasper Dupont
2006-03-03 15:10 ` Mario 'BitKoenig' Holbe
2006-03-04 13:16 ` Kasper Dupont
2006-03-04 13:38 ` Mario 'BitKoenig' Holbe
2006-03-04 19:50 ` Kasper Dupont
2006-03-07 10:47 ` Heinz Mauelshagen
2006-03-07 11:18 ` Kasper Dupont
2006-03-07 12:12 ` Heinz Mauelshagen
2006-03-10 7:43 ` Heinz Mauelshagen
2006-03-10 7:49 ` Kasper Dupont
2006-03-16 7:24 ` Kasper Dupont
2006-03-16 14:04 ` Heinz Mauelshagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060301215641.GA27042@hactar.lan \
--to=48755289462761382922@expires.02.sep.2006.kasperd.net \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.