On Wed, Feb 22, 2017 at 11:17 AM Phil Turmel <philip@xxxxxxxxxx> wrote: > > On 02/21/2017 08:12 PM, George Rapp wrote: > > > Before I proceed for real, does clearing the badblocks log and > > assembling the array seem like my best option? > > Yes. And consider disabling badblocks on all of your arrays. > > The badblocks feature does nothing but guarantee that errors > encountered on a device become uncorrectable, even if the cause > of the error was a transient communications or power problem, not > a true media flaw. Bad block tracking at the OS level is > appropriate for ancient MFM and RLL devices that lack modern > firmware, or similar low-level devices. And since the MD raid > bad block tracking feature does *not* provide redirects to > usable spare sectors, the feature is useless for such devices, > too. > > MD raid currently does *nothing* when a badblock entry reduces > the redundancy available for a particular sector in an array. > The badblocks feature is incomplete, has no upside for modern > component devices, and should not be used. OK, thanks. I removed the badblocks list as previously proposed and reassembled the RAID 5 array, and the reshape completed on 9 drives. I'm re-adding the tenth drive for redundancy before fsck'ing and mounting the filesystem to see what we've done. 8^) Current RAID status uploaded to https://app.box.com/v/raid-status-2017-02-22-txt for them as are interested. Thanks to all for your input and help! George -- 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
