Google 'sdparam'
-Ross
-----Original Message----- From: centos-bounces@centos.org centos-bounces@centos.org To: CentOS mailing list centos@centos.org Sent: Wed Dec 05 18:44:08 2007 Subject: RE: [CentOS] Re: SCSI bad block table display
From: Scott Silva Sent: December 5, 2007 15:09
on 12/5/2007 12:13 PM Hugh E Cruickshank spake the following:
Hi All:
Is there a utility available that will allow for the dump/display of the bad track table of a SCSI drive. We had this capability on SCO OSR5 but I have not been able to locate anything similar for Linux. The closest I have found is the badblocks utility that is part of the e2fsprogs package but this appears to only test for bad blocks not display the current bad block table contents.
I have done quite a bit of searching with Google but either it does not exist or (more than likely) I am using the wrong search parameters.
TIA
Regards, Hugh
Don't most modern drives cover up the bad blocks with controller logic and spare block substitutions?
All SCSI drives do this but what I am trying to do is display the contents of this "bad block" table. I have some suspect drives that had errors report but format fine at the controller level. I would like to see how many bad blocks the format encountered and remapped. If there are a large number of these then I do not want to use the drives in any critical applications. If the number is small then I will assume that the drive is basically fine to use and that the errors were localized.
Since I posted my original inquiry I have discovered that some of the drive manufacturers have T&D utilities that might allow me to get at this information. The main problem here is that they tend to be Windows based which means that I will need to setup a Windows system just to test the drives. I would rather test them in the systems that the will be running in (one is CentOS 4.5 and one is RHEL3). Seagate does have an older utility that supposedly will run at the Linux CLI (their terminology) which I will be trying out.
Regards, Hugh
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.
hec
I think most drives hide that info, although the manufacturers probably have diagnostics that can get to it. 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. 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. Once that happens, it is time to go drive shopping, and do a full backup (backup first I would say). 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.
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 are stored 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.
Regards, Hugh
-- Hugh E Cruickshank, Forward Software, www.forward-software.com
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.
From: Ross S. W. Walker Sent: December 5, 2007 22:07
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.
Thanks. I will definitely check that out.
Regards, Hugh
From: Hugh E Cruickshank Sent: December 6, 2007 11:42
From: Ross S. W. Walker Sent: December 5, 2007 22:07
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.
Thanks. I will definitely check that out.
The sg3_utils package and the sginfo command are exactly what I was looking for.
Thanks muchly.
Regards, Hugh
On Wed, 2007-12-05 at 17:29 -0800, 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'
<snip>
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 are stored 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.
Don't bother. It was implemented in the OS, including Xenix IIRC. The FS format had extra tracks reserved for remapping a whole track when one bad block was found in the original.
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!
*chuckle* If it ain't broken ...
<snip>
-- Bill
-
Hugh E Cruickshank -
Ross S. W. Walker -
Scott Silva -
William L. Maltby