Xref: utzoo unix-pc.general:2398 comp.sys.att:5743 Path: utzoo!utgpu!watmath!uunet!labrea!rutgers!mit-eddie!andante!ulysses!att!icus!lenny From: lenny@icus.islp.ny.us (Lenny Tropiano) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: questions about bad blocks Message-ID: <622@icus.islp.ny.us> Date: 5 Mar 89 07:35:58 GMT References: <732@bagend.UUCP> Reply-To: lenny@icus.islp.ny.us (Lenny Tropiano) Distribution: unix-pc Organization: ICUS Software Systems, Islip, New York Lines: 107 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