dealing with a failing drive
dnewman at networktest.com
Sun Nov 11 07:57:11 PST 2007
-----BEGIN PGP SIGNED MESSAGE-----
On 11/10/07 9:09 PM, Modulok wrote:
>>> I'd welcome suggestions on how (or whether) to try to revive a SCSI
> drive that's failing.
> It depends on how valuable the data on the array is, and more
> importantly, how much funding you have at your disposal to fix the
> problem. If it were me, I would set aside the bad disk, connect a new
> disk to the card and re-synchronize the array. (Assuming one of the
> members still retains a good copy of the data.) Afterwards I would
> destroy, or toss the existing disk in the trash can (depending on the
> sensitivity of the data stored on it.)
Thanks for your reply.
An update: After doing what you suggest (leaving in the "good" disk,
adding a new disk, RAID rebuilding) I still got soft write errors --
with *either one* of the disks I tried.
Then I tried putting both disks in an identical server and they came up
fine, no read or write errors.
Ergo, the bad RAID controller is bad and the disks may be OK.
>>> Is there some other way to:
>>> b)monitor the health of disks on a Compaq controller so it doesn't
> get to this point to begin with?
> There are various tools out there that attempt to 'monitor' the
> condition of disk drives to try and predict when failure is eminent.
> For valuable data, it is safer to setup a mirror and simply toss out
> bad disks as they fail. For extremely valuable data use a 3 disk
> array. With a 3 disk setup you will still be covered in the event that
> an additional disk craps out during the re-sync.
> To quote google's article on disk failure, regarding SMART:
Right, I've heard it said that "SMART isn't."
Nonetheless, I'd appreciate any suggestions to monitor the health of
disks -- and RAID controllers too -- on HP Proliant servers running FreeBSD.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
-----END PGP SIGNATURE-----
More information about the freebsd-questions