On 01/20/2016 01:43 PM, Chris Murphy wrote:
On Wed, Jan 20, 2016, 7:17 AM Lamar Owen <lowen@xxxxxxxx> wrote:
The standard Unix way of refreshing the disk contents is with
badblocks' non-destructive read-write test (badblocks -n or as the
-cc option to e2fsck, for ext2/3/4 filesystems).
This isn't applicable to RAID, which is what this thread is about. For
RAID, use scrub, that's what is for.
The badblocks read/write verification would need to be done on the RAID
member devices, not the aggregate md device, for member device level
remap. It might need to be done with the md offline, not sure. Scrub?
There is a scrub command (and package) in CentOS, but it's meant for
secure data erasure, and is not a non-destructive thing. Ah, you're
talking about what md will do if 'check' or 'repair' is written to the
appropriate location in the sysfs for the md in question. (This info is
in the md(4) man page).
The badblocks method fixes nothing if the sector is persistently bad and
the drive reports a read error.
The badblocks method will do a one-off read/write verification on a
member device; no, it won't do it automatically, true enough.
It fixes nothing if the command timeout is
reached before the drive either recovers or reports a read error.
Very true.
And even
if it works, you're relying on ECC recovered data rather than reading a
likely good copy from mirror or parity and writing that back to the bad
block.
Yes, for the member drive this is true. Since my storage here is
primarily on EMC Clariion, I'm not sure what the equivalent to EMC's
background verify would be for mdraid, since I've not needed that
functionality from mdraid. (I really don't like the term 'software
RAID' since at some level all RAID is software RAID, whether on a
storage processor or in the RAID controller's firmware.....). It does
appear that triggering a scrub from sysfs for a particular md might be
similar functionality, and would do the remap if inconsistent data is
found. This is a bit different from the old Unix way, but these are
newer times and such the way of doing things is different.
But all of this still requires the proper configuration.
Yes, this is very true.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
