Subject: Re: Disklabel ioctls (was Re: nore on disk ...)
To: None <firstname.lastname@example.org>
From: Leo Weppelman <email@example.com>
Date: 11/15/1995 12:47:00
> On Tue, 14 Nov 95 11:15:19 EST
> "Gordon W. Ross" <firstname.lastname@example.org> 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,
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