<div class="gmail_quote">On Tue, Apr 28, 2009 at 4:15 AM, Karanbir Singh <span dir="ltr"><<a href="mailto:mail-lists@karan.org" target="_blank">mail-lists@karan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>PJ Welsh wrote:<br>
> mdadm can resync, but so can the /proc with:<br>
<br>
</div>I must be missing something. What makes mdraid fail when a new kernel is<br>
installed ?</blockquote><div><br>I focused on the re-syncing part not the kernel part.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
<div><br>
> "echo check > /sys/block/md#/md/sync_action" for CentOS 5.x where "#" is<br>
> the number. In fact, if you don't do this on a regular basis, you *ARE*<br>
> asking for trouble!<br>
<br>
</div>umm.. Do you have some more details to back this statement up ? Are you<br>
saying that the image code is somehow broken in mdraid ?<br>
<br>
- KB<br>
<div><br></div></blockquote></div><br>UDE's (<i>undetected <b style="color: black; background-color: rgb(160, 255, 255);">disk</b> errors) and URE's (unrecoverable read errors) are growing very common with large capacity drives! These are silent killers of storage systems. ZFS is the only one at this time that automatically validates parity and checks for controller or drive issues actively. Every commercial product has a parity scrubbing process and so does Linux.<br>
<br><a href="http://en.wikipedia.org/wiki/Standard_RAID_levels">http://en.wikipedia.org/wiki/Standard_RAID_levels</a> (look in the "</i><span class="editsection"></span><span class="mw-headline">RAID 5 disk failure rate" sectinon) and lots of recent articles and postings:<br>
<br>It is essential to periodically validate the actually data on disk with a parity scrub!<br></span>