jan@bagend.UUCP (Jan Isley) (03/02/89)
I was formatting a disk Monday and when it finished formatting, it
announced that the drive had 14 entries in the bad block table.
This was *before* the media test was run and I did not enter any
bad blocks before I formatted the drive ... fresh out of the box.
What gives? How does it know that there are bad blocks before the
surface test is run?
Exactly where is the bad block table and how do I edit/delete it?
How can I add drives to the list on the diagnostics disk?
Lenny, your list is different than the 3.51 list ... anyone got
the source code?
After I ran the surface test and loaded the foundation set, I ran
iv -s /dev/rfp000
I have never had a problem doing this before, but this made the
system crash every time.
And on the subject of bad blocks: I know, we just went through part
of this recently but we did not finish it...
When you get something like this in /usr/adm/unix.log:
drv:0 part:2 blk:43763 rpts:1 Tue Jan 24 16:15:32 1989
drv:0 part:2 blk:43763 rpts:1 Tue Jan 24 16:35:02 1989
drv:0 part:2 blk:43763 rpts:2 Tue Jan 24 16:38:47 1989
drv:0 part:2 blk:43763 rpts:1 Tue Jan 24 16:43:12 1989
Is this a bad block looking for a place to happen? Yea, I know you can
use the recently posted blockfind to find the offending file. But, do
you panic immediately, find the file, copy it, add the bad block to the
table, delete the old file and fsck the disk, .... or what?
Do you do this on the first offense you notice? Or do you wait for
*possible* problems later?
Okay, I'll shut up now.
--
---
Jan Isley, follower of Zen, picker of nit
jan@bagend | {backbones}!gatech!bagend!jan | (404) 434-1335lenny@icus.islp.ny.us (Lenny Tropiano) (03/05/89)
In article <732@bagend.UUCP> jan@bagend.UUCP (Jan Isley) writes: |>I was formatting a disk Monday and when it finished formatting, it |>announced that the drive had 14 entries in the bad block table. |>This was *before* the media test was run and I did not enter any |>bad blocks before I formatted the drive ... fresh out of the box. |> |>What gives? How does it know that there are bad blocks before the |>surface test is run? |> Yes, according to most disk drive manufacturers (and something Gil told me) the bad block table is in a standard spot on the hard disk, and is in a standard format. So when the manufacturer puts the drive through bad block checking, it will write a bad block table. I was doing some *low level* formatting of a CRC Wren II the other day on a 3B2, and I was playing with the drive on a 3B1, it knew the bad blocks that we added with the 3B1 diagnostic disk, on the 3B2. |>Exactly where is the bad block table and how do I edit/delete it? |> You can edit it with the "Enter bad block option" from the diagnostic disk. At least you can add blocks, I don't know if you can delete blocks. My suggestion if you want to remove all the blocks in the bad block table is to zero it. Make sure you have a good list of bad blocks with the iv -vt /dev/rfp000 (or appropriate drive if you are fortunate to have two drives ;-) ) before you start zeroing bad blocks. Here's part of something I posted a while back that same subject ... |Subject: Re: Formatting 3b1 hard drives. |Summary: Clearing bad block tables... |Message-ID: <561@icus.islp.ny.us> |Date: 22 Dec 88 16:22:26 GMT |Organization: ICUS Software Systems, Islip, New York |Lines: 51 ... Here is a method used to CLEAR the entire bad block table. Be careful, this is dangerous. Make sure you perform a surface test afterwards. It would be a good idea to enter the bad blocks that was found on the drive by the manufacturer (usually on the label on the top of the drive, again open the case -- don't be afraid) Load diagnostics. type: s4test expert> 31 i> i <- Initialize i> dr 1 <- Hard Disk 1 i> i <- Initialize i> sb 0 <- Set sector buffer to 0's i> wr 2 <- Write to sector 2 i> rd 2 <- Read sector 2 into buffer i> sb <- Display buffer i> Q expert> U |>How can I add drives to the list on the diagnostics disk? |> |>Lenny, your list is different than the 3.51 list ... anyone got |>the source code? |> No, I don't have the source code. That diagnostic disk which has the *bigger* drives like the Maxtor XT1140 and XT2190 in there was something that someone with the sources did. You cannot add drives to that list without the source, and I don't have it :-( You can, though, use the option for "Others" and answer the questions appropriately for the drive parameters to format any kind of disk drive. Therefore, you don't need a specific option for your kind of drive. |>After I ran the surface test and loaded the foundation set, I ran |> |> iv -s /dev/rfp000 |> |>I have never had a problem doing this before, but this made the |>system crash every time. |> This can be dangerous. Doing a surface check on a mounted filesystem that is in use ... you are playing with the superblock, the vtoc, and the bad block table on a running system. If you were going to do this by hand I would suggest booting the floppy UNIX and then umount'ing the /dev/fp002 first. ... |>When you get something like this in /usr/adm/unix.log: |> |> drv:0 part:2 blk:43763 rpts:1 Tue Jan 24 16:15:32 1989 |> drv:0 part:2 blk:43763 rpts:1 Tue Jan 24 16:35:02 1989 |> drv:0 part:2 blk:43763 rpts:2 Tue Jan 24 16:38:47 1989 |> drv:0 part:2 blk:43763 rpts:1 Tue Jan 24 16:43:12 1989 |> |>Is this a bad block looking for a place to happen? Yea, I know you can |>use the recently posted blockfind to find the offending file. But, do |>you panic immediately, find the file, copy it, add the bad block to the |>table, delete the old file and fsck the disk, .... or what? |>Do you do this on the first offense you notice? Or do you wait for |>*possible* problems later? |> Well it wasn't the first offense. It was over a 1/2 hour period of time and you had 5 reports of that bad block. If the data at that block (if it is allocated to a file) isn't important, I would map the bad block. -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525 lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 {talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752