*This is my second attempt to send this to the list. If it shows up twice, I apologize.
We had a situation last year in which one of the aggregates on our R100 suffered dirty parity in one of its raid groups which forced us to take the filer down for several hours while we ran WAFL_Check on that aggregate. Given this, I have a few questions:
1. What is the likelihood of getting dirty parity? I assume the likelihood goes up dramatically on a box like the R100 given that the weekly RAID scrubs seldom if ever complete.
2. If this had occurred on a cluster, could we take one node down to run the WAFL_Check, while the other node continues to serve data from the other aggregates?
3. How many of you have encountered something like this and decided to go with SyncMirror to protect against such a thing?
Thanks,
--Carl
you could always change your raid scrub duration option to -1. this way it will run to completion.
On 3/7/07, Carl Howell chowell@uwf.edu wrote:
Hello,
as we are talking about scrubing...is there a way to see if the raid.scrub completes?? Is this posted to the messagelog or is there a command for control?
To the point about the cluster-functionality during a wafl_check i would guess that you have to disable the cluster before running this command. This is true for most operations you run during the bootprocess. My idea is, that the wafl_check cannot work correct if the data which has to be checked is changed all the time.
Regards
Jochen
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of tmac Sent: Wednesday, March 07, 2007 10:19 PM To: Carl Howell Cc: toasters@mathworks.com Subject: Re: Dirty Parity
you could always change your raid scrub duration option to -1. this way it will run to completion.
On 3/7/07, Carl Howell chowell@uwf.edu wrote:
*This is my second attempt to send this to the list. If it shows up
twice, I
apologize.
We had a situation last year in which one of the aggregates on our
R100
suffered dirty parity in one of its raid groups which forced us to
take the
filer down for several hours while we ran WAFL_Check on that
aggregate.
weekly
down to
run the WAFL_Check, while the other node continues to serve data from
the
decided to
If you want the raid scrubs to run through completion every week, then set the option raid.scrub.duration = -1 It always logs to the /etc/messages file when it completes. If you have not set the optoin, then it will tell you where it left off. When it starts back up, it will tell you where it is picking back up.
On 3/8/07, Willeke, Jochen Jochen.Willeke@wincor-nixdorf.com wrote:
I guess a better way to state the question is, what is the probability that something will happen at the RAID level, dirty parity for example, that will force you to take your cluster down? The thing that scares me is whether you've purchased a FAS270 or a FAS6070-HA, you will still have to take the cluster down to handle something that has gone wrong at the RAID/WAFL level. Right? You would have to utilize SyncMirror to be protected from something like this.
Jochen, the aggregate in my example would be offline. But I am fairly certain now that you are correct. The cluster would have to be down to fix the aggregate.
--Carl
-----Original Message----- From: tmac [mailto:tmacmd@gmail.com] Sent: Thursday, March 08, 2007 9:21 AM To: Willeke, Jochen Cc: Carl Howell; toasters@mathworks.com Subject: Re: Dirty Parity
If you want the raid scrubs to run through completion every week, then set the option raid.scrub.duration = -1 It always logs to the /etc/messages file when it completes. If you have not set the optoin, then it will tell you where it left off. When it starts back up, it will tell you where it is picking back up.
On 3/8/07, Willeke, Jochen Jochen.Willeke@wincor-nixdorf.com wrote:
would
guess that you have to disable the cluster before running this
command.
This is true for most operations you run during the bootprocess. My
idea
is, that the wafl_check cannot work correct if the data which has to
be
[mailto:owner-toasters@mathworks.com]
the
likelihood goes up dramatically on a box like the R100 given that
the
from
-
Carl Howell -
tmac -
Willeke, Jochen