On Aug 26,  2:45pm, Mark Gooderum wrote:
> > From: "Michael L. Hitch" <osymh@gemini.oscs.montana.edu>
> >   Both the SCSI hard disk (sd*) and CDROM (cd*) drivers take the b_blkno
> > field as the block number of a 512-byte (DEV_BSIZE) block and convert it
> > to the actual block number of the physical block of the disk....
>  
> This jives with the behavior I've seen.  Disklabel writes the label
> and reads it, okay, but fsck and newfs barf using the raw device about 
> 1/2 way through the disk (because block #'s are doubled...it runs off
> the end of the disk).

  If this is on the i386 port, I think this behaviour may be because the
bounds_check_with_label() routine doesn't take into account the physical
block size.  At the point that sd.c calls bounds_check_with_label(),
the partition size is in physical sector units, but the block number
and size are in DEV_BSIZE units.  The check is not being done correctly.
[I'm not certain how the disk label would be set up for the i386.  I
found that the partition size and partition offset had to be in units
of the device physical sector size in order for newfs to work correctly.]
Hmmm - an incorrect or inconsistent partition offset could be rather
dangerous.  It could easily cause newfs to write at the wrong spot on
the disk.

> I would love to help make this work (I've got a couple of older but very
> big 1024 block SCSI drives I scrounged that otherwise work).
>  
> I've played a bit with having physio() stuff the block value into both
> b_lblkno and b_blkno.  

  I don't think will work - the getblk() routine in kern/vfs_bio.c is
already setting b_lblkno and b_blkno to the specified block.  It might
work better if physio() ensured that b_lbkno was zeroed.

> So far it doesn't quite work yet.  I still get the symptom that
> I can label the disk, but fsck barfs, and the kernel complains about
> no disk label when first booting.

  If fsck is still having problems thinking it's going off the end of
the partition, that problem is probably because bounds_check_with_label()
doesn't take into account the difference in the units between the
partition size and the block number + I/O length.

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA

------------------------------------------------------------------------------