On Wed, 8 Apr 1998, Simon Raahauge DeSantis wrote:

> On Wed, 8 Apr 1998, Bob Nestor wrote:
> > The Mkfs and Install Utilities share the same low-level disk I/O 
> > routines.  I'm not sure what the Booter uses, but it may be just some 
> > higher-level MacOS I/O stuff.  Anyway I've been working on upgrading Mkfs 
> > to handle IDE and the alternate SCSI Bus stuff.  I lifted the code from 
> > pdisk in the DR2.1 Update 6 release of MkLinux.  So far I have all the 
> > low-level disk I/O stuff working and now all I need to do is finish up 
> > the menus and import newfs from NetBSD. (Right now the code can find and 
> > identify everything I have on my systems, both IDE and SCSI.) I'd planned 
> > on using the current version of newfs as it supports both BSD4.2 and 
> > BSD4.4 filesystems, although the Installer only handles BSD4.2 right now. 
> >  I don't know when I'll finish this effort, but if I knew we had someone 
> > actively working on the IDE support in NetBSD/mac68k I'd try a little 
> > harder.
> > 
> > -bob
> On a somewhat related note, will the installer ever be upgraded to handle
> BSD4.4 filesystems? When I got a new hard drive a few months ago I had
> some trouble using mkfs on it, so I just newfs'd it. Now none of my six
> partitions (on two hard drives) are usuable in the Installer. This isn't a
> special concern to me since my MacOS partition is only something like 15
> megs, holding a minimal system and a few NetBSD utils (like the booter).
> It does affect my ability to mount the filesystems in the Installer's
> minishell so I can cpout to floppy disks and such.
> 
> -Simon Raahauge DeSantis

You can make a partition that works with the Installer, or the Booter
even, using `newfs -O etc...' In fact, my Quantum 1G did not
leave me any other choice--with the Mkfs made filesystem, NetBSD would
crash into the debugger while unpacking the distribution, or fscking. 
The message I got was
	
	panic: ffs_alloccgblk: can't find blk in cyls.

A trace included the following routines: ffs_alloccgblk, ffs_alloccg,
ffs_hashtable, ffs_balloc, ffs_write, vn_write. 

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: 

fredb-> newfs -NO -k40,43 -m10 -r5400 -x1 sd0a
	or even
fredb-> newfs -NO -x1 sd0a
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.]

(The -N option is necessary, due to the fact that I'm currently running
from this drive!) I'd like to send-pr on this, but I'm not quite sure what
to make of it.  FWB's geometry doesn't add up either. Their sectors/track
is all wrong. I'm letting newfs get that from the in kernel disklabel. 
What I don't understand, is how newfs can correctly skip over the bad
blocks without knowing where the cylinders end. Here's part of the
disklabel from the same drive: 

4 partitions:
#        size   offset    fstype   [fsize bsize   cpg]
  a:  1957120    88960      4.2BSD        0     0     0   # (Cyl.  160 - 3679)
  b:    86180  2046080        swap                        # (Cyl. 3680 - 3834)
  c:  2132260        0      unused        0     0         # (Cyl.    0 - 3834)
  d:    87872     1088         HFS                        # (Cyl.    1*- 159*)
disklabel: boot block size 0
disklabel: super block size 0

and the probe results:

sd0 at scsibus0 targ 4 lun 0: <QUANTUM, FIREBALL1080S, 1Q09> SCSI2 0/direct fixed
sd0: 1041MB, 3835 cyl, 4 head, 139 sec, 512 bytes/sect x 2132260 sectors

I would very much appreciate an explanation from someone who understands this.