[Info-vax] Problems detected with analyze/disk

[Bob Gezelter]

On Nov 23, 10:41 am, "Richard B. Gilbert" <rgilber... at comcast.net>
wrote:
> Bob Gezelter wrote:
> > On Nov 22, 6:16 am, anwa <anders_s_wal... at yahoo.se> wrote:
> >> Hi,
>
> >> After running anal/disk I have encountered some problems. I am running
> >> VMS V8.3 on Itanium with ODS5 disks.
> >> The faulty files are reported with only the "name+typ" parts of the
> >> file spec. There are several names with the same name and version
> >> number belonging to different users. There are also som corrupt(?)
> >> file names.
>
> >> - How do I find the correct file based on this information?
> >> - Can I use the file-id (xxxx,yy,z) to access the files and copy/
> >> delete them?
>
> >> All hints greatly appreciated.
>
> >> Anders Wallin
>
> >> =========== partial extract from anal/disk ===========================
>
> >> %ANALDISK-W-MULTALLOC, file (288980,11,0) TCPIP$REXEC_RUN.LOG;185
> >>         multiply allocated blocks
> >>         VBN 1 to 16
> >>         LBN 36358752 to 36358767, RVN 1
> >> %ANALDISK-W-MULTALLOC, file (708146,53,0) °ç 0ê Pê
> >>         multiply allocated blocks
> >>         VBN 99681 to 99696
> >>         LBN 36358752 to 36358767, RVN 1
> >> %ANALDISK-W-MULTALLOC, file (708146,53,0) °ç 0ê Pê
> >>         multiply allocated blocks
> >>         VBN 99697 to 99712
> >>         LBN 36358768 to 36358783, RVN 1
> >> %ANALDISK-W-MULTALLOC, file (83148,96,0) INDATA.BCK;2
> >>         multiply allocated blocks
> >>         VBN 13953 to 13968
> >>         LBN 36358768 to 36358783, RVN 1
> >> %ANALDISK-W-MULTALLOC, file (708146,53,0) °ç 0ê Pê
> >>         multiply allocated blocks
> >>         VBN 99713 to 99728
> >>         LBN 36358784 to 36358799, RVN 1
> >> %ANALDISK-W-MULTALLOC, file (156375,23,0) MP_OHW.OPT;2
> >>         multiply allocated blocks
> >>         VBN 1 to 16
> >>         LBN 36358784 to 36358799, RVN 1
>
> > anwa,
>
> > I would recommend extreme caution here. With all due respect, the
> > problem can be far more subtle than is clear from the responses that
> > have been posted.
>
> > Just because a small number of files PRESENTLY show multiple
> > allocations does not not mean that they are the only files affected by
> > this over the time that the problem has been happening. If file that
> > is subject to this is revised, the new copy may be correctly
> > allocated, but contain corrupted data. There are also other cases that
> > can happen.
>
> > I would counsel an immediate BACKUP/PHYSICAL of the affected drives to
> > secure media, followed by a careful audit of all files on the disks.
>
> With that BACKUP/PHYSICAL you can always restore the original sad state
> of affairs!  If your efforts at repair make matters worse, you can
> always restore and try something else.
>
> An ANALYZE DISK_STRUCTURE should follow the backup in order to get a
> reading on just what is wrong, files affected, etc.  Files that appear
> intact can be copied to another disk.
>
> It may be helpful to keep a careful log.  Record everything you do and
> the result of each action.
>
> Most of your data is probably still present and can probably be salvaged
> if doing so is worth the time and effort.  Direct your attention to data
> written since the last known good backup.
>
> <snip>

Richard,

Actually, while it may be influenced by the forensic component of my
practice, I tend to preserve the original corrupted volume "on the
shelf" and work on a copy. Thus the original is undoubtedly preserved
for whatever reason may become necessary.

- Bob Gezelter, http://www.rlgsc.com