Very Computer

If a hard drive has bad blocks, can Tru64 mark them in the FS, and
continue to use the drive?  Or does the drive simply need to be
replaced?

Tru64 5.0a, advFS, scsi hd, alphastation 500.

Since I have to wipe the disk anyway, would it help for me to change the
OS or FS?

Quote:>If a hard drive has bad blocks, can Tru64 mark them in the FS, and
>continue to use the drive?  Or does the drive simply need to be
>replaced?

To answer the question asked, wouldn't answer the real question
because you've made an assumption about how it works that doesn't
apply.  Neither UFS nor AdvFS do any management of bad blocks.
They leave that to the drive and underlying driver.  They'll
report bad blocks when they encounter them and react appropriately
(if inconviently).

Most well behaved SCSI drives support a command called "Reassign
Blocks".  In SCSI-2 this is an optional command and not all drives
may support it.  The scu(8) gives access to the command using
"reassign lba".  Most well behaved drives will try fairly extensive
error recovery and if allowed by their firmware options will replace
the block themselves.  The driver will do the same thing they and
if it manages to get a good copy of data, will use the command to
replace the block.

When a good copy of data can't be obtained, the only real choice
is to leave the block bad since the consumers of the block are
the only ones that know how to deal with corrupt data.  As mentioned
before, both UFS and AdvFS will report the block.  Each has tools
that allow finding how the block is used, so you can best determine
how to handle the corruption.  The AdvFS admin. guide (usually on
with the AdvFS Utilities on the Associated Product CDROM), should
discuss how to deal with bad blocks.  For file data is may be a
simple matter of replacing the bad block with scu(8) and restoreing
the file from a backup to write the correct data to whatever block
is allocated for it.

Errors in file system metadata area are harder to deal with, which
is why reading the documentation may be of use.

--

Quote:> To answer the question asked, wouldn't answer the real question
> because you've made an assumption about how it works that doesn't
> apply.  Neither UFS nor AdvFS do any management of bad blocks.
> They leave that to the drive and underlying driver.  They'll
> report bad blocks when they encounter them and react appropriately
> (if inconviently).

Thank you, that was exactly the source of my confusion.

Quote:> "reassign lba".  Most well behaved drives will try fairly extensive
> error recovery and if allowed by their firmware options will replace
> the block themselves.  The driver will do the same thing they and

Correct me if I'm wrong, but the FS stores a list of blocks that belong to a file.  Right?  So if block
reassignment is done transparently at the hardware/firmware level, the block numbering must be rearranged, so
it is no longer linear, and the same block number now corresponds to different physical data.  This implies
that prior to the reassignment, there existed a finite number of blocks, to which no block numbering had been
assigned.
If this is the case, I have more confusion, but it's probably wrong somehow.

I will go read the AdvFS admin guide now.
I'll also read about scu.

Quote:>> "reassign lba".  Most well behaved drives will try fairly extensive
>> error recovery and if allowed by their firmware options will replace
>> the block themselves.  The driver will do the same thing they and

>Correct me if I'm wrong, but the FS stores a list of blocks that belong to a file.  Right?  So if block
>reassignment is done transparently at the hardware/firmware level, the block numbering must be rearranged, so
>it is no longer linear, and the same block number now corresponds to different physical data.  This implies
>that prior to the reassignment, there existed a finite number of blocks, to which no block numbering had been
>assigned.
>If this is the case, I have more confusion, but it's probably wrong somehow.

The scu(8) command calls it "lba" for a reason; logical block address.  The
drive handles the level of indirection needed to presents a linear logical
block space where the underlying physical blocks may be elsewhere.  Good
disk design ensures that some replacement blocks are "nearby" so that
the performance loss of using a replacement block is minimal.  Since
most drives have some replaced blocks as shipped from the factor, there's
always some need to go a little out of the way to get the data.

I think the general layout on some of our old MSCP disks was; a block
or two on each track (no more than a rotation away), a whole surface
of blocks (one track per cylinder, just a head switch away) and
a bunch of spare cylinders on the inside or outside.

--