> On Tue, 14 Nov 95 11:15:19 EST 
>  "Gordon W. Ross" <gwr@mc.com> wrote:
> 
>  > Or do it like SunOS: <sun/dkio.h>
>  > 
>  > /*
>  >  * Disk io control commands
>  >  */
>  > #define	DKIOCGGEOM _IOR(d, 2, struct dk_geom)	/* Get geometry */
>  > #define	DKIOCSGEOM _IOW(d, 3, struct dk_geom)	/* Set geometry */
>  > #define	DKIOCGPART _IOR(d, 4, struct dk_map)	/* Get partition info */
>  > #define	DKIOCSPART _IOW(d, 5, struct dk_map)	/* Set partition info */
>  > #define	DKIOCINFO  _IOR(d, 8, struct dk_info)	/* Get info */
> 
> Yah, it would be nice to have these implemented, if nothing else than for 
> the sake of binary compatibility.
> 
> However, I suggested the semantics I did given that we have:
> 
> 	DIOCGDINFO	get disklabel
> 	DIOCSDINFO	set in-core disklabel
> 	DIOCWDINFO	set in-core disklabel, update disk
> 	DIOCGPART	get partition info; only really useful in kernel
> 
> Since our disklabel contains geometry (albeit potentially incorrect if 
> misconfigured) and partition info, it seems like something to just ask 
> the disk for geometry was more in order.  Sort of like a "generic" 
> version of a SCSI rigid-geometry mode-sense and indentify.  Maybe this 
> could be generalized a bit more and provide vendor, model, and revision 
> strings, if applicable.
I think you are right, given the current structure of the disklabel.

> 
> Actually, I've been thinking about disklabels lately; that 30-minute 
> commute gives me that opportunity.  I've been getting pretty frustrated 
> at some of the stupidity in our current disklabel semantics.  I think 
> what bugs me the most is the fact that on some devices, notably SCSI, the 
> total size of the disk is often a few to several blocks larger than:
> 
> 	sectors/track * tracks/cylinder * cylinders
I usually have my pocket calculator ready when setting the disklabel.
Dependent on the disk, you might win a nice swap-device ;-) You can
also gain some space when you partition on cylinder boundaries.

> 
> Indeed, I have a couple of disk manuals at work that flat out say that 
> the disk's reported geometry is _estimated_ based on observed averages.
This is because the number of sectors/track differs with the position of
the head above the platters. The current notion of disklabel/newfs and
friends about cylinders and tracks is rather outdated.
> 
> Disklabel(8)'s inability to deal with this is a problem.  For example, 
> you have a new SCSI disk, you install it, and proceed to install the 
> disklabel.  disklabel(8) chokes because partition `c' (or, whichever 
> RAW_PART happens to be on your system... *ahem*) runs past end of unit.  
> I.e. disklabel(8) did the math, and determined that your absolutely 
> correct disklabel is in error.  (Remember: MI SCSI and other drivers set 
> the size of RAW_PART and some geometry info in the disklabel if no label 
> is read off disk).  So, wanting to label the disk, you shrink `c'.  BZZT!
> Can't do that either; "open partition would move or shrink".
If I remember well, alot of grief can be spared when disklabel(8) would
take the values of:
	d_subtype, d_secperunit, d_sparespertrack,d_sparespercyl, d_acylinders,
	d_bbsize, d_sbsize
from the cpu-disklabel after the call to getasciilabel(). This is one of
the outstanding items on my todo list. I have a patch lying around here
to do just that. If you want to try it, tell me. I haven't thought about
it for quite some time - too busy with other parts...
> 
> So, the way I bypassed this in the hp300 install.sh is, well, sickening:
> 
> 	* Increase the number of cylinders by one.  Add a dummy partition
> 	  (a in this example) of offset 0, size 1 (block).  Label disk, using 
> 	  `disklabel -r -R /dev/rsd?c labelfile'.
> 	* Run `disklabel -e /dev/rsd?a'.  Adjust cylinders back to proper
> 	  value, and adjust the size of `c' so that the math works out.
> 	* Run `disklabel -e /dev/rsd?c' again and actually edit the
> 	  partition map to your liking.
> 
> I would propose something along these lines:
[ Lots of ideas deleted ]
I agree with the basic ideas you presented here. I wonder however if it
is really needed to shrink/grow the raw-partition. If nobody is having
'smart' ideas about disksizes and just adhere to what the disk is saying,
this shouldn't be needed. 
> 
> 	  Any program taking advantage of this interface is inherently
> 	  machine-dependent, and should be condemned spend it's days in
> 	  /usr/mdec.

Leo.