26 Jan
2008
26 Jan
'08
4:35 p.m.
Dave Dunfield wrote:
Do you know a reason why VMS would write that
"high" on the drive
during a simple restore (minimal system) and subsequent boot. I
know it would put dir/maps in the middle, but this is a fair way
above the middle.
I don't know exactly where the issue lies here. You have a virtual
1.5GB RA92. SIMH hasn't seen fit to ask for a 1.5GB file yet,
just a 1GB one. I presume that this means that SIMH will grow the
file dynamically. As for why that much of the disk has been used,
I don't know. I do know that and image backup followed by a
restore was the recommended way of defragmenting disks
for a long time. So backup will "rearrange" things. I guess it boils
down to how the filesystem goes looking for available blocks,
and I don't remember how that works in detail. I do know
that the default INIT places the bitmap and other "high usage"
things in the middle (as you've found). That's because it used to cut
down
seek times back in the days of days of RA60s and RL02s.
It may well be that the allocation scheme works from the middle
of the disk outwards, or something like that.
I don't know if I can capture the output of SIMH,
but I will
try to do this on a real vax later today and capture the output.
I didn't do /FULL, this was just the #blocks listed in the short
listing.
If it's this one:
KRAKAR> sh dev dka0
Device Device Error Volume Free
Trans Mnt
Name Status Count Label Blocks
Count Cnt
$1$DKA0: (KRAKAR) Mounted 0 OPENVMS071 28246713
424 1
KRAKAR>
then that's just the _free_ block size.
No SHOW DEV involved - the 1331208 number came by
dividing the actual
size of the CD image file by 512. - Just looking to understand why it
behaves differently - Perhaps SIMH adjusts the blocksize somehow, so
this is not the actual size of the disk created.
Going back to your RA92 initial query, that's a 1.5GB disk. So that's
roughly 3,000,000 blocks, give or take. You installed VMS onto that.
What you saw was 2,479,032 blocks, but if that's the output of SHOW DEV
(and not SHOW DEV/FULL) then that's the free blocks. So your VMS install
ate up 500,000 blocks (or ~250MB or so). The exact size of the VMS
install
depends on how big a PAGEFILE and SWAPFILE you gave it, but 250MB
seems perfectly reasonable.
Given what you say, I think that you are reading the output of SHOW DEV
and not realising that this is the number of free blocks. Maybe.
Wouldn't this result in trying to boot a full
image on the CD
(although
I could specifically boot stabackup assuming it's on the image). My
goal was to put stabackup and a save set on the CD.
You want a bootable CD along with a saveset that you can then use
to restore to a new disk? That's fine. I'd still go the LD route,
backing up to a saveset on the LD disk and building SABKP on the
LD disk, but I just like LD :-)
If you are doing this to restore a data CD you don't strictly
need SABKP on that CD. You can build SABKP on any disk attached
to the machine: so you can install SABKP on the system disk. Then
you boot SABKP off the system disk (/R5=E0000000 iirc) and
restore the saveset.
Back in the day, there was a strong recommendation to having
SABKP on the system disk (and on a few data disks too, in case
the system disk was the one you needed to restore and its
SABKP had gone south). Booting a SABKP on a VAX-11/750 off a
local disk took a few minutes. Doing the same thing using
TU58 took almost an hour (and you needed to swap TU58s once
or twice!). There was even a command procedure that would
"optimise" your TU58s by putting stuff on there in the order
that the boot process asked for them - shaved maybe 10 minutes
off the overall time!
Yes, I really do mean it - I have two 3100 series
machines which
suffer from the limitation, and I want to put 1G drives in them - but
all of
my 1G drives are "just a little too big". Please elaborate on the
"tricks".
What I mean is that I want to create a 650M image to burn to the CD,
however I don't have any 650M drives - I've got LOTS of 1G drives,
so if I could mount them smaller (650M or less) I could create a
filesystem on them that will fit on a CD.
Pick up LDDRIVER from the OpenVMS Freeware and install. Use
SYSGEN to create a 650MB contiguous file on your 1GB disk, tell
LD about the file and have it map LDA1: to it. You now have
a 650MB disk (LDA1:) that is conveniently stored on your
disk as a file.
But I don't think it really matters - What I will
probably do is
transfer an image of the drive to SIMH where I can then perform a
backup of it to a virtual disk which can be any size I want.
That also works.
Q: Is stand-alone backup from OpenVMS 7.x compatible
with older
version filesystems? - If I backup my VMS 5.5 disk using stabackup
from 7.2, and restore it with same, will I get a workable VMS 5.5
system disk again? I haven't tried booting 5.5 under SIMH yet - If
for some reason it doesn't work, then I may need to do this with
the OpenVMS utilities.
It most certainly had better be backwards compatible at least as
far as ODS-1 used on VAX/VMS 1.0! OK, I've never gone that far
back, but I would consider it a bug (and a fairly serious one, given
that this is BACKUP!) if this did not work.
Antonio
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.11/1244 - Release Date:
25/01/2008 19:44