Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!decwrl!sun!mojo
From: mojo@sun.uucp (Joseph Moran)
Newsgroups: net.unix-wizards
Subject: Re: C partition
Message-ID: <7473@sun.uucp>
Date: Sun, 21-Sep-86 01:51:27 EDT
Article-I.D.: sun.7473
Posted: Sun Sep 21 01:51:27 1986
Date-Received: Sun, 21-Sep-86 18:40:57 EDT
Organization: Sun Microsystems, Inc.
Lines: 67

In article <8609182044.AA08511@jade.Berkeley.Edu> mike@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@sun.COM (or mojo@sun.ARPA)