RE: Re: SCSI bad block table display

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux