On Sun, Jun 2, 2013 at 6:53 AM, Phil Turmel <philip@xxxxxxxxxx> wrote:
[trim /]
>
> There are numerous discussions in the archives... search them for
> combinations of "scterc", "tler", and "ure".
>
It appears this has been a frequent issue over the last year. Thank
you for the background information, I understand what I was reading.
>
> So your device role order is /dev/sd{c,b,d,e}1.
[trim /]
> Anyways, the quickest way for you to have a running array is to use
> "mdadm --assemble --force /dev/md0 /dev/sd{c,b,e}1". This leaves out
> the first dropped disk. Any remaining UREs cannot be corrected while
> degraded, but the data on the first dropped disk is suspect.
>
> Feel free to use an overlay on /dev/md0 itself while making your first
> attempt to mount and access the data. If you cannot get critical data,
> stop and re-assemble with all four devices.
>
> Phil
>
Thanks, I will do that.
I am correct in thinking that I should not set scterc to 7 seconds
initially, since there will not be any parity to correct the read
errors? Best would be to set the driver time-out to 180 seconds until
after the array is rebuilt?
I am concerned about read errors during the rebuild. With a failed and
rebuilding array, will the get drive kicked on an URE? Is it better to
use something like badblocks or dd_rescue to correct/mark the sectors
first and then rebuild? Either way, I'm going to lose that data, but
maybe there are some better tools for extracting data from a bad
sector?
After the rebuild is complete, I should set the scterc to 7 seconds
and add a bitmap based write-intent log?
Does anyone learn these things the easy way :)
Much appreciated, Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
