NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/bsd/4055

Internet Message Format | 1992-08-12 | 4.5 KB

Path: sparky!uunet!usc!rpi!batcomputer!munnari.oz.au!asgard!mjj
From: [e-mail] (Murray Jensen)
Newsgroups: comp.unix.bsd
Subject: Re: 2nd drive file ... (Actually wd ESDI problems)
Summary: bad144 area plus possible multi-sector read problem
Message-ID: <[e-mail]>
Date: 12 Aug 92 14:45:15 GMT
References: <[e-mail]> <[e-mail]> <tih.713450893@barsoom>
Organization: CSIRO Division of Manufacturing Technology, Melbourne, Australia
Lines: 74

[e-mail] (Tom Ivar Helbekkmo):
> [e-mail] (Bernard Steiner) writes:
>>I noticed that with my ESDI drives I had to give disklabel one cylinder less
>>than what the physical drive parameters are...
> I thought of this too, but I've tried reducing the number of available
> cylinders to about a fourth of the real number with no improvement...

The area bad144 uses is at the end of *partition C*. It is supposed to use
only the last track + 126 sectors, but since you usually want filesystems
to be whole numbers of cylinders you might as well leave the whole last
cylinder free. The distributed disktab says you should leave 5 cylinders
for bad sector stuff, but after looking at this a bit I decided it was
wrong - can someone who knows for sure please comment?

In any case, the important thing is that it is at the end of partition C,
whatever part of the disk that may cover - with DOS partitioning, it won't
be the entire disk. The way you leave space for bad144 is to not have any
of the A, B, E, F, G & H partitions cover that last cylinder (or last 5
cylinders) of partition C. This means of course that you can't put a
filesystem on partition C if you are using bad144. Think of it like this:
partition C *contains* partitions A, B, E, F, G, H *and* the bad144 area,
none of which should overlap if they exist.

A couple of notes - partition D *always* covers the entire physical disk
and all sector offsets in the disktab entry and disk label are relative
to sector zero of the physical disk. This becomes very important if you
are using DOS partitioning. Let me illustrate this with an example - I
have a 140Mb Micropolis 1355 ESDI drive with the first 40Mb for DOS and
the rest (100Mb) for 386BSD. Disk geometry is 1021 cylinders, 8 heads and
35 sectors/track:

          size    offset    cylinders
    A:     10360     80640     288- 324
    B:     30800     91000   325- 434
    C:    205240     80640     288-1020
    D:    285880         0       0-1020
    E:     80080       560       2- 287
    H:    163800    121800     435-1019

The DOS partitions are set up such that the DOS5 partition covers cylinders
2-287 and the 386BSD partition covers cylinders 288-1020 (I had a bad sector
in cylinder 0 or 1 so DOS had to start its partition at cylinder 2). I have
set partition E up to cover the DOS area, and I should be able to use mtools
on it to access my DOS files although I haven't tried it yet.

Now on to my problem: someone posted about using dd on the block device to
find out where the bad sectors are. I did this, added them to the bad144
table and dd would then run through without errors. (Trick - use the
following: "dd if=/dev/wd0c of=/dev/null bs=512 conv=sync,noerror" and you
will get all the bad blocks in one hit - though I think read-ahead may cause
each bad block to be reported multiple times with incrementing numbers - just
ignore all but the first bad block in a sequence and rerun it to be sure)

However, fsck would still fail - quite badly too - obviously because there
were still bad sectors on the disk. But I had not got any errors from dd on
the block device, so I tried fsck on the block device and it ran through
perfectly!

My guess is that the BSD filesystem sector clustering code, which groups
sectors together to form larger "logical blocks" (I was using 4096 byte
logical blocks i.e. 8 sectors, in my filesystems - other people use 8192)
is somehow avoiding the bad144 bad sector forwarding mechanism when it
does the multiple sector read (or write). I am in a catch-22 situation
here - I can't fix it until I fix it! So I am hoping that someone else
has already run into (and fixed) this. Can anyone help me with this?
                            Murray...
PS: In case it matters: 386SX/25, 8Mb RAM, Mega EVA/2 (ET4000) VGA,
Micropolis 1355 on Ultrastor Ultra-12F controller (no sector slipping,
DOS can't handle it), QIC02 60Mb cartridge tape, 4 serial, 2 parallel,
Adlib sound card, 1.44 & 1.2 Mb floppies.
--
Murray Jensen, CSIRO Div of Manufacturing Tech,     Phone: [phone]
Locked Bag No. 9, Preston, Vic, 3072, Australia.      Fax: [phone]
Internet: [e-mail]               ACSnet: [e-mail]