Re: Searching, but not finding...

Re: Searching, but not finding...

[Neil Brown]

On Mon, 10 May 2010 13:07:44 -0700
Daniel Boggs <BecauseImAwesome@Live.com> wrote:

> My apologies Neil,
> 
> I tried to follow your direction and e-mail linux-raid@vger.kernel.org with
> the below e-mail, but it was returned as no longer valid.  I do not wish to
> bother you, and if you can redirect me to a better place to ask the below
> question, I will happily take direction.

linux-raid@vger.kernel.org definitely works, and I have taken the liberty of
copying this reply to that list.
I believe that vger.kernel.org is configured to reject mail containing HTML,
and you mail did contain HTML, so maybe that was the problem.

> 
> 
> After years of trial and error I am finally transferring my entire RAID to
> linux as a software RAID.  I have wanted to do it for some time, but just
> did not have the linux expertise to get it done.  My RAID 6 is building as I
> write this, but this is one feature I have not been able to locate.  Most of
> the hardware RAID I have used in the past had something called "Dynamic
> Sector Repair"  where it would do a low impact check through the raid to
> confirm and dynamically repair any damaged sectors or data. This is an
> amazing capability since it drastically reduces the likelihood of a
> catastrophic failure during a drive rebuild or some similar action.  Does
> mdadm have this capability at all?  Would it be possible to add it?  If not,
> are you aware of any apps that could?

We call this "scrubbing" mostly, and it is effecfed by:

  echo check > /sys/block/mdXX/md/sync_action

This will cause the array to read every block and check for consistency.  If
it hits a read error it will handle it the way all read errors are handled,
which is to compute the correct data from else where and write it back so the
drive has a chance to repair or relocate the sector.

It would probably make sense to add a function to mdadm to do this so that it
would be better documented by I haven't yet (though I accept patches....)

NeilBrown


> 
> If this is written in the documentation and I just missed it I apologize.
>  My understanding of linux is still on the low end.  Thank you for your
> time!
> 
>
> Daniel

Re: Searching, but not finding...

[Daniel Boggs]

Question:

If I use:

>>> echo repair > /sys/block/mdX/md/sync_action

to start a check action, then stop it with

>>> echo idle > /sys/block/mdX/md/sync_action

and later start it up again.  Will it start again from the
"beginning", or is it able to pick up where it left off?

Essentially if I find the repair/sync action causes too much of a
performance hit, could I have it run only during hours that I know the
array will not be in use and still have the array checked in its
entirety, or is the only way to accomplish that to let the action run
from start to finish?
--
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

Re: Searching, but not finding...

[Neil Brown]

On Mon, 10 May 2010 15:49:20 -0700
Daniel Boggs <BecauseImAwesome@Live.com> wrote:

> Question:
> 
> If I use:
> 
> >>> echo repair > /sys/block/mdX/md/sync_action
> 
> to start a check action, then stop it with
> 
> >>> echo idle > /sys/block/mdX/md/sync_action
> 
> and later start it up again.  Will it start again from the
> "beginning", or is it able to pick up where it left off?

Yes .. if you have a recent enough kernel.

When you write 'idle' you should find the current sector stored in 'sync_min'.
When you write 'repair' again it will start from the value in 'sync_min'.
Obviously if you stop and restart the array you will loose this value unless
you store it in a file somewhere and recover it.


> 
> Essentially if I find the repair/sync action causes too much of a
> performance hit, could I have it run only during hours that I know the
> array will not be in use and still have the array checked in its
> entirety, or is the only way to accomplish that to let the action run
> from start to finish?

You can also reduce the impact by slowing down the scan using sync_speed_min
and sync_speed_max.   'min' is an upper limit to the speed when other IO is
happening, and 'max' is an upper limit when there is no other IO.

NeilBrown


> --
> 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

--
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