dealing with a failing drive

Jerry McAllister jerrymc at
Mon Nov 12 08:17:58 PST 2007

On Sun, Nov 11, 2007 at 07:56:52AM -0800, David Newman wrote:

> Hash: SHA1
> 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.

Probably not.
Generally, if the RAID controller is bad, you will see errors
all over and not it just one place, tho I suppose it is possible.
Check and see what it reports as error locations and see if they
move around any.

A soft error is usually one that can be corrected within the limits
of rereads and any error correction that the system is using.  It
may be that the error was introduced when the problems with the old
disk was occuring so that there was an error written on to the other
supposedly good disk and then mirrored to the new disk - errors can
be preserved by mirroring too.

Having said that, I don't know where this error is from.  Try reading up
and rewriting the data that is in the spot getting the error and then 
reading it from the new location.   It is pretty hard to figure out
and specifically rewrite one certain block on modern systems because
the physical locations are virtual.   Although you would expect the
same sector number to be in the same place from one write to the next,
if it happens that that sector gets remapped due to an error, then
it will actually be a different physical location the next time and
you don't really prove anything.   But, it is worth experimenting 
with if you want.

You can dd from and to any sector on the partition by carefully
using skip counts and block counts.   But, you have to figure out
the location (sector number) first.

Good luck,


> >>> 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.
> thanks again.
> dn
> Version: GnuPG v1.4.1 (Darwin)
> dZjf3ynK+4OffBzsDOawF9A=
> =DUqc
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"

More information about the freebsd-questions mailing list