On Thu, 9 Apr 1998, Dave Huang wrote:

> On Thu, 9 Apr 1998, Frederick Bruckman wrote:
> > Viewing the mode pages with FWB's SCSI config, it looked like this drive
> > is moderately unusual in that it had reserved one bad block per CYLINDER,
> > vs. the more conventional one or two per SECTOR. Mkfs doesn't permit this
> > option, but newfs does (-x1). It works. I've been running from this drive
> > for about a week now.  newfs complains, however: 
> 
> One or two bad blocks reserved per SECTOR?? Wouldn't that be reserving
> 1/2 or 2/3rds of the drive for bad blocks?

That's for sure. What I meant to say, was blocks/cyl vs. blocks/track.

> So what happened when you didn't use -x1? I'm sure -x1
> works fine, but you're losing a bit of disk space... (probably only a
> few hundred K, so it's no big deal)

What happened was the system crashed into the kernel debugger on any kind
of heavy disk activity, even an fsck in single user. The message was

        panic: ffs_alloccgblk: can't find blk in cyls.

> > newfs: Warning: calculated sectors per cylinder (555) disagrees with disk
> > label (556)
> > 
> > Warning: 365 sector(s) in last cylinder unallocated
> > /dev/rsd0a:     1957120 sectors in 3527 cylinders of 4 tracks, 139 sectors
> >         955.6MB in 221 cyl groups (16 c/g, 4.34MB/g, 1088 i/g)
> > [etc.]
> 
> I'm not sure if I've seen that first message before, but the second one
> (365 sectors ...) seems very common.

That's a consequence of using -x1 with newfs. Without it, all the blocks
get used, but the system crashes. I did it both ways a couple of times to
be sure it was real. All I can think of now, is that there's a problem
with a single block somewhere on the drive. Perhaps, by scrambling things
up, that block is being avoided, for now anyway. I'm not so sure about
that either. On another drive, the Nomai 540M that I used to boot NetBSD
from, a block was replaced automatically, just the way it's supposed to.
vis, I got a media error from reading one file, consistently, but it went
away after rewriting that file. Never crashed.

> I think it's just that ffs was designed back when drives
> had a fixed numbers of sectors/track, so the total disk capacity was
> (# of sectors/track) * (# of tracks/cylinder) * (# of cylinders).
> Nowadays, drives have more sectors on the outer tracks than on the inner
> tracks, so the number of sectors/track reported is just sortof an
> average so that (# of sectors) * (# of tracks) * (# of cylinders) is
> close to the size of the disk, but not exactly the same. BTW, if you
> really really want to know, you can get the actual number of
> sectors/track by looking at mode page 12, the notch page. It'll tell you
> that the drive has n0 sectors from cylinder s0 to e0, n1 sectors from
> cylinder s1 to e1, etc...

Very interesting. Inspired by your explanation, I dug into this a bit and
found it it's only slightly more difficult than that. You have to change
the notch in page 12, then go back and read pages 3 and 4 for each notch.
Totalling up all 15 notches, the capacity matches that given by the probe. 

> Anyways, I always do a plain "newfs /dev/whatever", and it's been
> working fine for me. Did it just yesterday, 'cuz I got a replacement
> for my NetBSD drive that died. Restored the system from tape and it's
> happy again :)

Good for you! In my case, I really wanted to use this drive with NetBSD,
but it didn't work, so I was willing to experiment. It works fine now.
I'm reporting this in the hope that it will help someone in a similar
predicament. The only moral to be drawn from this, really, is to "push
all the buttons."

I have another drive that passes the probe, and sits on the bus without
any problems. It's an Arriva brand, Quantum 3080 mechanism. Any access at
all, however, dd, or disklabel, causes the system to crash immediately
after the information is returned. I was able to read Mac files with
hfsutils and NetBSD1.2, but all the more recent kernels have a problem
with it. I'm willing to correspond privately with anyone who has ideas on
this.