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.
Given this, I have a few questions:
What is the likelihood of getting dirty parity? I assume thelikelihood goes up dramatically on a box like the R100 given that the
weekly
RAID scrubs seldom if ever complete.
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?
How many of you have encountered something like this and
decided to
go with SyncMirror to protect against such a thing?
Thanks,
--Carl