C partition
Joseph Moran
mojo at sun.uucp
Sun Sep 21 15:51:27 AEST 1986
In article <8609182044.AA08511 at jade.Berkeley.Edu> mike at wisdom.BITNET (Mike Trachtman) writes:
>I just thought of a simple extension to the Sun approach
>of having the partition information on the disk itself.
>
>In addition, how about an ioctl, that can change the
>size of the partition.
>(one to read the size into a user program, and one
>to reset the size).
>
>The one to set the size would be doable by root only of course.
>
>In any case, in general the C partition,
>would not include bad block areas; the area that describes the partitioning
>of the disk, or anyother purposefully transparent area.
>
>Special utilities, such as disk copiers, or bad block repairers, or whatever,
>would set change the partitions dynamically, so as to do their stuff,
>and then when done, restore things to the way they were.
>
>Presumeable, tables of where interesting information is,
>i.e. bad block info, and or special headers are, would be kept in a file.
>
>This should give the best of all worlds,
>
>mike
>
> Mike Trachtman
Well I guess we have the best of all worlds then. In addition to
having disk partitioning read per disk, Sun supports ioctl's to change
the driver's idea of the disk partitioning. Knowledgeable UNIX programs
can also change the permanent disk partitioning by writing the
structures to the right places on the disk (e.g. like the `setup'
program does when the partitioning is changed). However, the disk
information about bad block info are not kept in a UNIX file - there is
no need to. (Actually there are several reasons why you shouldn't do
it, is the UNIX driver going to interpret file system types? And
besides, there is actually a boot strap problem here - what comes
first, the bad block mapping or the UNIX file system used to contain
the bad block info?) We simply have conventions as to how the
"alternate" cylinders are used for each disk type (SMD, ST506, ESDI).
In any case, you're right - it is nice to have per disk partitioning
and ioctl's to over ride them.
>From <sun/dkio.h>:
#define DKIOCGPART _IOR(d, 4, struct dk_map) /* Get partition info */
#define DKIOCSPART _IOW(d, 5, struct dk_map) /* Set partition info */
The dk_map structure is defined in <sun/dklabel.h>. This ioctl allows
one partition size (e.g. the `c' partition) to be changed. This ioctl
has been around at Sun for a LONG time.
In Sun release 3.2 there is another new ioctl which allows all the
partition sizes to be changed in one shot. Also from <sun/dkio.h>:
#define DKIOCSAPART _IOW(d, 123, struct dk_allmap) /* Set all partitions */
#define DKIOCGAPART _IOR(d, 122, struct dk_allmap) /* Get all partitions */
Again, my use of Sun as an example is simply because I'm familiar with
them. But speaking as someone whose fought some disk battles in my
days, I think that it is really silly to have UNIX systems that DON'T
support some of these disk features.
Joseph Moran
{ihnp4, decvax, seismo, decwrl, ...}!sun!mojo
mojo at sun.COM (or mojo at sun.ARPA)
More information about the Comp.unix.wizards
mailing list