Hugh E Cruickshank wrote:
From: Scott Silva Sent: December 5, 2007 16:32
on 12/5/2007 4:21 PM Hugh E Cruickshank spake the following:
From: Ross S. W. Walker Sent: December 5, 2007 15:49
Google 'sdparam'
Thanks. While that seems to be on the right track it does
not appear
to dump/display the bad block table.
I think most drives hide that info, although the manufacturers probably have diagnostics that can get to it.
While that may be the case with IDE/SATA drives it should not be the case with SCSI (not sure about SAS). The reporting should be pretty standard for all SCSI drives.
I think you are looking for something similar to what you you did with the old MFM drives when you entered the bad block table in at format time.
No, I am definitely thinking SCSI. I would like to get at the same information that SCO OSR5 would report with the badtrk utility.
Smart utilities usually can only tell you how many spares are used and how many are left, or just if there are more bad sectors than the drive had spares for.
For SCSI this table should be available for display. According to the SCO OSR5 badtrk man page:
Bad tracks/blocks listed in the table are ``aliased'' to good tracks/blocks; when a process tries to read or write a track/block listed in the bad track/block table, it is replaced by one of the alias tracks/blocks. The bad track/block table and alias tracks/blocks arestored in the disk partition, after the division table and before division 0.
Now that I have reread that several times it is starting to sound more like this functionality may have been implemented a the OS level and not in the drive as I had previously thought. I will have to go back and find our for sure.
You know it amazing sometimes how you can have a wrong perception in your head for years and never have it challenged or have cause to question it. When I say years I mean many years. I have had 20+ years of using UNIX systems and this is the first time that I have ever had cause to question this. Just goes to show you live and learn!
Once that happens, it is time to go drive shopping, and do a full backup (backup first I would say).
Agreed. In my case all drives are mirrored (most H/W mirroring on MegaRAID controllers and some S/W RAID on Adaptec controllers) so that is usually not a problem for me.
The MegaRAID controllers are really spoiling me. If a drive fails I just pull the bad drive, pop in a new drive and the controller takes care of the rest. You hardly even notice any degradation while the new mirror is constructed.
The modern controllers shouldn't have bad blocks mapped to usable sectors unless the drive is heading to the great e-waste box in the sky.
Again I was not thinking of the controller (or HBA) I was thinking of the drive itself.
Anyway thanks for all your comments.
I found what I think your looking for, sg3_utils, it's in extras I believe. Part of that set is sginfo and that command takes a -G parameter which will show the grown defect list if the device supports it.
Neither my SATA nor SAS disks here support it so I wasn't able to get anything useful out of it.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.