Re: VAX VMS 7.3, ana/image running out of virtual memory ?
- From: "Bob Gezelter" <gezelter@xxxxxxxxx>
- Date: 14 Dec 2006 03:00:16 -0800
Jur,
WADU, I must disagree with the comment about bound volume sets. They
may be far less needed and used than in prior years, but they remain a
useful capability. Conceptually, I consider them to be a different
dimension of flexibility, with the other dimensions being the RAID
dimensions of striping and shadowing. Before the (recent) advent of
Dynamic Volume Expansion, volume sets were the only effective way to
increase storage capacity of a user volume that could be done without a
DISMOUNT/MOUNT sequence and consequent interruption of user activities.
In days past, volume sets were the only way of increasing usable
"single" volume size beyond the limits of the actual disks, the largest
of which (e.g., the size of a full size home clothes washer or dryer)
were 80-300 MB.
With disk drives quickly approaching the terabyte range, and
intelligent mass storage subsystems virtuallizing storage across their
drives, this is less needed, but not unneeded. That said, it is
important to be careful with one's maintenance.
- Bob Gezelter, http://www.rlgsc.com
Jur van der Burg wrote:
Ok, mea culpa.
It's a bug in LDdriver, I just reproduced it and it's present for a
long time (since LD V8.0), on all platforms. Older versions are not
affected. It's a one line change, it is always writing to the member
of a bound volume set where the containerfile is created (normally
the first one).
So stay away from LD and bound volumesets for now. I'm not surprised
that it did not show up before as volumesets are evil, albeit supported.
There's not used much anymore nowadays.
This is one of the very few bugs in LD, and I'm sorry to see that it
had such severe consequenses.
A fix is on the way, I'll update my website later tonight.
http://www.digiater.nl/lddriver
Jur.
JF Mezei wrote:
SHORT STORY: I have a corrupted bound volume set thanks to VMS's
no-longer so robust software. I should have stayed with 7.2.
QUESTION: can I safely ANA/IMAGE individual drives in a bound volume
set ? trying to analyse the whole volume fails. Are there other tools to
fix a drive that is corrupted with some file data having been overwritten ?
(THE LD driver used was on Alpha 8.3 accessing the bound volume via MSCP).
Am not a happy puppy. (presently doing a backup to see how much of the
drive can be recuperated, but I have no idea how many files have had
their actual data overwritten and which may not signal any error until
you try to look at the actual contents). (like my TPU$COMMANDS.TPU file
which was overwritten with junk).
I have a bound volume set (4 dssi disks of 2gigs). Tonight, while
creating some ISO container files, I filled the volume. I quickly
deleted files to make space.
However while using BACKUP to populate an ISO container file (LDA device:)
%BACKUP-S-CREATED, created LDA1:[VMS$COMMON.SYSLIB]DDTM$XA_SS.EXE;1
%BACKUP-S-CREATED, created LDA1:[VMS$COMMON.SYSLIB]DDTM$XG.EXE;1
%BACKUP-S-CREATED, created LDA1:[VMS$COMMON.SYSLIB]DDTM$XG_SS.EXE;1
%BACKUP-S-CREATED, created LDA1:[VMS$COMMON.SYSLIB]DDTM_XA.H;1
%BACKUP-S-CREATED, created LDA1:[VMS$COMMON.SYSLIB]DEBUG.EXE;1
%BACKUP-I-BTCROUT, routine Write error detected, output Status, Call
RESTORE_ERROR
%BACKUP-I-VALUE_TRACE_D, Decimal trace value 844
%BACKUP-E-WRITEBLOCK, error writing block 5293 of
LDA1:[VMS$COMMON.SYSLIB]DEBUGSHR.EXE;1
-SYSTEM-F-IVADDR, invalid media address
%SYSTEM-F-ABORT, abort
$ show dev lda1:/full
OK, figured perhaps it was some problem with LD Driver on alpha
accessing a bound volume served by a 7.3 vax.
But then...
$ edit sys$manager:systartup_vms.com
%DCL-S-SPAWNED, process JFMEZEI_1 spawned
$
%TPU-E-READERR, error reading USRDIR:[JFMEZEI]TPU$COMMAND.TPU;2
-RMS-F-IRC, illegal record encountered; VBN or record number = 1
And now:
$ ana/disk/repair $disk2
Analyze/Disk_Structure/Repair for _$4$DIA1: started on 13-DEC-2006
06:06:53.72
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
%ANALDISK-I-BADHIGHWATER, file (431,5,1) AUSTRALIA.DXF;5
inconsistent highwater mark and EFBLK
%ANALDISK-F-ALLOCMEM, error allocating virtual memory
-LIB-F-INSVIRMEM, insufficient virtual memory
$
-----------------
I have never seen ANA/DISK run out of virtual memory and was always able
to do this ana/disk on that bound volume set.
OK, and now:
DUMP USRDIR:[JFMEZEI]TPU$COMMAND.TPU;2
Yield only garbage date in it.
irtual block number 1 (00000001), 512 (0200) bytes
00000000 00000031 00000000 00000000 ........1....... 000000
0015E768 0015E758 58000000 00000040 @......XXç..hç.. 000010
00000000 00000032 00000000 00000000 ........2....... 000020
0015E780 0015E770 58001800 00000040 @......Xpç...ç.. 000030
00000000 00000031 00000000 00000000 ........1....... 000040
0015E798 0015E788 58000800 00000040 @......X.ç...ç.. 000050
00000008 00000031 00000000 00000000 ........1....... 000060
0015E7B8 0015E7A8 5800B000 00000040 @....°.X¨ç..¸ç.. 000070
DAMNED VAX 7.3. It broke the OSU web server and had now corrupted my
main disk (just before I was to move it to new drives and get rid of
this bound volume set).
.
- References:
- VAX VMS 7.3, ana/image running out of virtual memory ?
- From: JF Mezei
- Re: VAX VMS 7.3, ana/image running out of virtual memory ?
- From: Jur van der Burg
- VAX VMS 7.3, ana/image running out of virtual memory ?
- Prev by Date: dsw41/42 and dsv11
- Next by Date: Re: DEC 3000/400 problems
- Previous by thread: Re: VAX VMS 7.3, ana/image running out of virtual memory ?
- Next by thread: Alpha 8.3 BACKUP and bound volumes, size reporting
- Index(es):
Relevant Pages
|
Loading