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:
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 nodedown 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 anddecided to
go with SyncMirror to protect against such a thing?
Thanks,
--Carl
-- --tmac
RedHat Certified Engineer
Principal Consultant, RABA Technologies 240-373-3926 (office) 301-688-4705 (Lab) 214-279-3926 (eFAX)