cottrell@nbs-vms.ARPA (COTTRELL, JAMES) (09/18/85)
/* > >About that c partition... c accesses the whole disk including > >the space reserved bad blocks. > --- > Wizards: Is this really true? Yes. > Am I playing with fire by having a c partition > on a CDC 9766 (like an RM05) controlled by an SI 9400 controller? Yes and No. As long as you never back up disk packs by making identical copies via `dd' you will be okay. If your disks are perfect (no bad blox) you can even do that. Don't let the disk get too full tho, or that last track might get allocated as data. Hopefully, they should be the last blox allocated. When you make your file system partition C, give it less blox. Sutract off that last track. Change the `pc' parameter in /etc/disktab from 500384 to 499776. I see no reason to include the last track in the C partition description. SUN 2.0 doesn't. Try to keep straight what's going on here tho. The hp driver has the limits of the partitions wired into it. Partitions start where /etc/disktab says they do and are only as big as it says. If you want to make them smaller fine. The driver never looks at /etc/disktab tho. Newfs does. You can always make an almost duplicate entry, say ZDZ9766 and then do `newfs hp#c ZDZ9766'. The super block says the disk is short, but you can get at the last track thru the raw device. > I'm interested in the c partition part, ... > not in flames about the 9766 or SI. How about a testimony then? We have an SI 9900 (not 9400) controlling an eagle and a 9766. SI gave us a tape with a new hp.c along with a bunch of utilities. How does *online* formatting sound to you!?! And bad block redirexion with the bad data automatically forwarded! And it even works on our DEC RM03's & our other SI 9400 controlling two 9762 (RM03's). Only (cosmetic) complaint is that everytime the system boots (or mounts the A partition) the bad block list prints on the console. Should be easy to remove tho, or redirect somewhere else. > I'm running under VAX 4.1 BSD UNIX. I'm running 4.2 & have never seen 4.1, so I might be off the wall. > Jon Eichelberger > eichelbe@NADC jim cottrell@nbs */ ------
gnu@l5.uucp (John Gilmore) (09/28/85)
In article <1579@brl-tgr.ARPA>, cottrell@nbs-vms.ARPA (COTTRELL, JAMES) writes: > > >About that c partition... c accesses the whole disk including > > >the space reserved bad blocks. > > Wizards: Is this really true? > Yes. > When you make your file system partition C, give it > less blox. Sutract off that last track. Change the `pc' parameter in > /etc/disktab from 500384 to 499776. I see no reason to include the last > track in the C partition description. SUN 2.0 doesn't. Sun Unix has never included the bad block area in the partitions. That sounds like a suicidal idea to me. Then again, Sun Unix puts a *label* on the disk which identifies where the partitions are, rather than having random numbers hard-coded into the disk drivers and assorted files in /etc. Users can hack this label with a standalone program (or indeed from Unix, using the raw device). When the system boots (or mounts the disk), it reads the label to figure out where the partitions are, and there's an ioctl to pass the info back to things like newfs or mkfs or fsck. Given that this setup is totally different from what you find on Vaxen (at least in 4.2), what Sun Unix does or does not do is not really relevant to how you build tables for Vaxen.
pwd@pid.UUCP (Philip W. Dalrymple) (10/02/85)
In article <165@l5.uucp> gnu@l5.uucp (John Gilmore) writes: >In article <1579@brl-tgr.ARPA>, cottrell@nbs-vms.ARPA (COTTRELL, JAMES) writes: >> > >About that c partition... c accesses the whole disk including >> > >the space reserved bad blocks. >> > Wizards: Is this really true? >> Yes. > >Sun Unix has never included the bad block area in the partitions. >That sounds like a suicidal idea to me. Then again, Sun Unix puts >a *label* on the disk which identifies where the partitions are, rather The Fortune does the same thing (they call it the configuration and it also containes the bad block list ). -- Philip Dalrymple akgua!pid!pwd 404/429-8266 (voice)
mike@wisdom.BITNET (Mike Trachtman) (09/19/86)
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
My address:
mike@wisdom (BITNET)
mike%wisdom.bitnet@wiscvm.ARPA (ARPA/CSNET)
mike%wisdom.bitnet@berkley (ARPA/CSNET)
and if all else fails (ONLY for VERY short items)
...!decvax!humus!wisdom!mike (UUCP)
Physical: Michael Trachtman
Applied Math Department
Weizmann Institute of Science
Rehovot, Israel.mojo@sun.uucp (Joseph Moran) (09/21/86)
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)
jdb@mordor.ARPA (John Bruner) (09/24/86)
Sun's partition table on the disc is very convenient. Unfortunately, their placement of it is not. They put the disc label in the first sector on the volume. This is OK if your machine's ROM knows about it, but if the hardware bootstrap wants to read block 0 (as the VAX does) it is a little inconvenient. :-) An obvious alternative would be block 15 (the last 512 bytes of the first 8K), provided that the size of the boot program at the beginning of the disc is limited to 7.5K. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
amir@booboo.UUCP (09/25/86)
> 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). > On our UTX release, we do have the capability to read the disk partition sizes (plus other useful info like the disk geometry). As a matter of fact, our "newfs" figures out all the "mkfs" parameters by using this ioctl. > 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. > I am not sure how useful this would be. I guess it is kind of hardware dependent. For example, our disk controllers require tracks to be reformatted to allow for automatic flaw handling. I don't see how a "disk repair" utilitiy could use standard Unix IO to do this. We accoumplish this by doing physical IO to the drive which bypasses the disk driver anyways. Also, when would you want to copy the bad block info from one disk to another??? Amir H. Majidimehr Gould Inc, Computer Systems Division {sun,pur-ee,brl-bmd}!gould!amir -- Amir H. Majidimehr Gould Inc, Computer Systems Division {sun,pur-ee,brl-bmd}!gould!amir