23 Jun
2020
23 Jun
'20
6:03 p.m.
So I'm working on this RSX11M+ system here and while working I ran
myself out of file headers. Using the HOME /MXF command I was able to
increase the number of headers, but only up to 4090. or so. Trying to go
to 4100 gave me an error saying there were not enough system blocks or
something. Currently I have 830 headers, but that's not enough in the
long term.
The volume has 541,944 blocks total, with 150655 in use. This is a
system I generated on a smaller disk, then copied to the pdp11, then
backed up with BRU MU0:=DU0: then restored to a larger blank disk.
I guess the question is can I extend the number of blocks without having
to re-init the system disk? I suppose I could flatten it by taking the
system down to single user (shutdown, then p to start with the volume
dismounted, mount the volume /for, then BRU mu0:=du0:), then format the
volume with a really big assed MXF value, then restoring the tape, but
would that flatten the volume info? Or do I need to just man up, put a
second ESDI drive on this monster, copy the files to the second drive
then format the first (big) volume right, copy the files with PIP, and
do a VMR again to write the boot block?
Or is there a better way to backup and restore the volume without doing
an image backup using /for?
Been a long time since I've done this stuff. Thanks!
C
24 Jun
24 Jun
9:57 a.m.
On Tue, Jun 23, 2020 at 9:03 PM Chris Zach via cctalk <cctalk at classiccmp.org>
wrote:
So I'm working on this RSX11M+ system here and
while working I ran
myself out of file headers. Using the HOME /MXF command I was able to
increase the number of headers, but only up to 4090. or so. Trying to go
to 4100 gave me an error saying there were not enough system blocks or
something. Currently I have 830 headers, but that's not enough in the
long term.
I've never actually used RSX-11 myself, all I know about it is what I read
in the ODS-1 spec, but I'm guessing the issue here is that the volume is
set up with only 1 block allocated for the index file bitmap, and growing
the number of file headers beyond 4096 would require growing the index
file bitmap to 2 blocks (or more, depending on how many file headers you
expect to need). Since the first 16 file headers must follow directly after
the index file bitmap, growing the bitmap requires moving those first 16
file headers as well, which in turn requires moving whatever may currently
be in the way. None of this of course is something I'd expect the system
to be able to do while the volume is mounted.
What precisely you have to do to achieve the goal of having a volume
with more file headers I can't say, sorry, but I thought I could at least
provide some extra context for other readers on why it's not as trivial to
do as one might guess.
-ken
10:37 a.m.
I did get an answer from Johnny B, and it makes sense why I couldn't
figure it out: In order to increase the file handles significantly you
have to either dismount with "dmo du0:/dev/lock=v" to lock tasks in
memory then mount foreign and back it up or just put BRU64K on an RX01
floppy with VMRV48 and boot from that.
Then after the volume is backed up to tape you clobber it by using BRU
to restore it and set the /MXF parameter on that line. Otherwise BRU
keeps the same value for MXF and the files limit is still there.
The neat part (and why I couldn't remember) is I used to use DSC to back
up my RL02's and RM02's to other RL/RM disk packs. DSC did a pretty much
image copy while BRU actually creates a new file system and then copies
the files and the boot information. I didn't use BRU at the time because
I didn't have a tape drive.
Modern technology marches on. I'm waiting on a pair of TK50 tapes to
arrive from TrashBay, once I have those checked out I'll do the backup
and restore and get myself back in business.
C
* Dismounting the system volume on RSX11 is tricky. You can just
dismount it, but then the system will lock you out of installed tasks
and you'll be dead in the water. The /dev/lock=v holds the tasks in
memory so you can still run your tools with the disk dismounted.
A quick way to do this is to bring up the system, then shutdown and when
you get to ODT type P to proceed. The system will come up with the shell
but no volumes.
Using HOM can increase the number of files or directories but only up to
a point. Also with home you need to first set the device to private
(only do-able when you do the shutdown and resume with P trick) then
allocate the disk, then mount it foreign.
It's never dull in pdp11 world.
CZ
On 6/24/2020 12:57 PM, Kenneth Gober wrote:
On Tue, Jun 23, 2020 at 9:03 PM Chris Zach via cctalk
<cctalk at classiccmp.org <mailto:cctalk at classiccmp.org>> wrote:
So I'm working on this RSX11M+ system here and while working I ran
myself out of file headers. Using the HOME /MXF command I was able to
increase the number of headers, but only up to 4090. or so. Trying
to go
to 4100 gave me an error saying there were not enough system blocks or
something. Currently I have 830 headers, but that's not enough in the
long term.
I've never actually used RSX-11 myself, all I know about it is what I read
in the ODS-1 spec, but I'm guessing the issue here is that the volume is
set up with only 1 block allocated for the index file bitmap, and growing
the number of file headers beyond 4096 would require growing the index
file bitmap to 2 blocks (or more, depending on how many file headers you
expect to need).? Since the first 16 file headers must follow directly after
the index file bitmap, growing the bitmap requires moving those first 16
file headers as well, which in turn requires moving whatever may currently
be in the way.? None of this of course is something I'd expect the system
to be able to do while the volume is mounted.
What precisely you have to do to achieve the goal of having a volume
with more file headers I can't say, sorry, but I thought I could at least
provide some extra context for other readers on why it's not as trivial to
do as one might guess.
-ken
1420
days inactive
1420
days old
2 comments
2 participants
participants (2)
-
cz＠alembic.crystel.com -
kgober＠gmail.com