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 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.
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
