4 Aug
1999
4 Aug
'99
4:49 p.m.
OK, as long as I don't run into any unforseen
trouble that keeps me from
having time, I plan on installing RT-11 on a large disk in the next few
days. However, I won't be using the nice WQESD ESDI controller that I've
got that makes partitioning disks easy. So I want to make sure I
understand how partitioning works under RT-11.
Doesn't it do the partitioning in hardware anyway? Of course that is
easy... they become separate units...
If I'm reading the manuals correctly I would first
boot off of my RL02
pack and do the following
.INIT/BADBLOCKS DU0:
then
.SQUEEZE/OUTPUT=DU0: DL1:
.COPY/BOOT DL1:RT11FB.SYS DU0:
That should be
.SQUEEZE/OUTPUT:DU0: DL1:
.COPY/BOOT DU0:RT11FB.SYS DU0:
and then boot the system from DU0: So far that's
pretty straight
forward, and except for using SQUEEZE to copy the distribution, pretty
much the way I got it from RX50 to RL02.
Squeeze is a faster way of doing the copy when the output volume is
a freshly initialized volume. You could do it with a COPY/SYS...
Now then since I'll want to use more than just the
first 30Mb of the Hard
Drive, I'll need to set up partitions. Do I do this prior to
initializing DU0: or after booting from a freshly installed DU0:?
There are a number of factors involved... you need to ensure that the
partitioning in the DU driver you are using to write to the DU device
is the same as the DU driver which gets written *to* that device. If
not, you could write the data just fine, but not be able to find it
easily.
An example of this might be having a specially-partitioned XM version of
the DU driver. You use it to copy a system to some other partition,
but you set it to boot RT11FB (which uses a different copy of DU -- the
one built for SB/FB) and then boot the volume... when it gets up far
enough that it tries to use the FB version of the handler, it references
an entirely different partition.
I realize the command to do the partitioning is:
.SET DU0 UNIT=0,PORT=0,PART=0
.SET DU1 UNIT=0,PORT=0,PART=1
.SET DU2 UNIT=0,PORT=0,PART=2
.SET DU3 UNIT=0,PORT=0,PART=3
Personally, I like to think more hierarchically, doing the PORT, then
UNIT, then PARTition. But yes, this could work. I also tend to keep
the DU0-DU3 devices mapped to partition zero of the corresponding
physical units:
.SET DU0 PORT=0,UNIT=0,PART=0
.SET DU1 PORT=0,UNIT=1,PART=0
.SET DU2 PORT=0,UNIT=2,PART=0
.SET DU3 PORT=0,UNIT=3,PART=0
and then assign the non-zero partitions to DU4-DU7 (this is with a handler
without the extended unit support, of course).
Also I assume that a partition has to be 65,535 blocks,
but does the last
one have to be that, or will it simply be however much space is left?
It is automatic. All partitions other than the final one will be
65536 (not 65535) blocks in size. The last one will be whatever is
leftover (total_size % 65536). BTW - although the partitions are
65536 blocks in size, the last block is reserved, so the effective
size is 65535.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+