[Info-vax] Problems detected with analyze/disk

[Richard B. Gilbert]

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>