Re: Anal/dis/rep/read

Wim Van den Wyngaert · ‎10-03-2004

I do anal/dis/rep/read on a station with 1 disk.
I get :

ANALDISK-W-READFILE (2126,1,0)
error reading VBN325
SYSTEM-F-PARITY, parity error

I thought this was a temporary file but after a reboot I get the same result (same fileid).

How is this possible ? How can I delete and recreate this file ?

Wim

Wim

Bojan Nemec · ‎10-03-2004

Hi,

Can you find out which file is this? Have you try:

$ PIPE DIR/FILE/NOHEAD/COL=1 disc:[*...] | SEA SYS$PIPE "(2126,1,0)"

Or there is an LOSTHEADER for this file?

Bojan

Uwe Zessin · ‎10-03-2004

You normally get prompted to recover lost files to [SYSLOST]. I would first try and find out a bit more about the file, perhaps it is entered in a directory anyway and you have discovered a bug:

$ dump/header/blocks=count=0/identifier=(11516,7,0) dsa0:

.

Wim Van den Wyngaert · ‎10-03-2004

Bojan,

Did that with output to a file and searched the file (pipe doesn't allow /window and with your statement you don't see the name).

Result : debug.exe.

Why didn't anal/dis/rep/read report this name and dir did ?

Uwe : I specified /repair. So if it was lost : it should get repaired. No ?

Wim

Uwe Zessin · ‎10-03-2004

Ah, I see that you did not specifiy /CONFIRM. In that case you don't get prompted and lost files usually get automatically entered in [SYSLOST], but as I already wrote: you might have discovered a bug in VMS.

Have you tried the command I gave you? Did you get any useful output?

.

labadie_1 · ‎10-03-2004

Uwe answer is perfectly correct, but I like DFU
$ mc dfu
search disk/fid=(2126)

labadie_1 · ‎10-03-2004

a little improvement

$ pipe dump/header/block=count=0/ident=(14633,1,0) dra1: | sea sys$pipe "File name:"

gives File name: XXX

:-)

Wim Van den Wyngaert · ‎10-03-2004

All,

I recreated debug.exe. No more parity errors now.

So, why wasn't the name debug.exe given by anal ?

Wim

labadie_1 · ‎10-03-2004

I find in the doc

ANALYZE/DISK_STRUCTURE Output

------------------------
By default, the Analyze/Disk_Structure utility directs all output to your terminal. If you prefer, you can use the /LIST qualifier to generate a file containing the following information for each file on the disk:

File identification (FID)
File name
Owner
Errors associated with the file

-----------------------

so you shoud add /list to get the file name

source:
http://www.pi-net.dyndns.org/docs/openvms0731/731final/6048/6048pro_005.html

Wim Van den Wyngaert · ‎10-03-2004

Gerard,

I think this is not correct. /list will give you a list of all files.

Normally, anal will report the file name. For some unknown reason it didn't (corruption ?). The dir command is getting its info elsewere and did find the name.

So, why didn't anal report the file name ?

Wim

Wim

labadie_1 · ‎10-03-2004

Well I do not know.

The example in the doc has files by file-id and file name, with the same lostheader message.

%VERIFY-W-LOSTHEADER, file (16,1,1) []X.X;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (17,1,1) []Y.Y;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (18,1,1) []Z.Z;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (19,1,1) []X.X;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (20,1,1) []Y.Y;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (21,1,1) []Z.;1
not found in a directory
%VERIFY-W-LOSTHEADER, file (22,1,1) []Z.;2
not found in a directory
%VERIFY-W-LOSTHEADER, file (23,1,1) LOGIN.COM;163
not found in a directory
%VERIFY-W-LOSTHEADER, file (24,1,1) MANYACL.COM;1
not found in a directory

Gerard, puzzled

Ian Miller. · ‎10-03-2004

Re /LIST - according to the manual - lists all files. "If you specify /LIST, the utility produces a file that contains a listing of ALL file identifications (FIDs), file names, and file owners.". Not a particularly useful feature generally.

The original problem is fixed but what you are commenting on now is why the utility did not give the filename as well as the fileid in the original message - is that correct?

____________________
Purely Personal Opinion

Wim Van den Wyngaert · ‎10-03-2004

Yes Ian. Normally the name is not given if the file is temporary (t.i. already deleted but still open) or spooled (don't know how that works in detail).

Wim

Wim

Hein van den Heuvel · ‎10-03-2004

>>> The example in the doc has files by file-id and file name, with the same lostheader message.

But this topic was not about a 'lostheader'.
It was triggered by the /read telling analyze to read all allocated blocks on the disk.
One of those was bad reporting an IO problem

Wim, I would not expect a bad block to clear over a reboot. If it was in a temp file, and that file was deleted, then analyze would not need to re-read and that could hide the problem.
If after reboot the block is re-used (for an other, or for 'the same' file), then the write operation may actually trigger clearing the problem (relocating the disk block).

>> I recreated debug.exe. No more parity errors now.

As per above... deleting the old file would have been needed to hide it, rewrite to clear it.

>> So, why wasn't the name debug.exe given by anal ?

Good question! Sorry, no answer.

Btw 1... DUMP/HEAD is the only command that does not need file-number + file-id. Just a file number will do.

Btw 2... other then the file name, you may want to use the mapping table in the header to determine whcih physical block was mapped by vbn 325.

Hein.

Uwe Zessin · ‎10-03-2004

A file that was created through the spooling mechanism is never entered into a directory. It can have a name recorded in the file header anyway - that is why you can see []BLA.DAT;1

When you delete an open file, sometimes just the directory entry is removed - the file header is maked unused when the file is really closed. A 'temporary' file is one that never was entered into a directory - there is an option that can be specified on file CREATE. I am sure the spooling mechanism uses the same feature.

Again, the behaviour of ANALDISK looks like a bug to me. It is very likely that nobody of us can answer your persistent 'why'. You have to talk with the maintainer (HP).

.

Bojan Nemec · ‎10-04-2004

Wim,

Sorry for the wrong pipe, I should test it.

My opinion is, that anal reads the indexfile and dir reads the directory. Both files contains the file name and the file id.

So, as Uwe suggested, try to look to the dump/head (this is the dump of the index file). Examine the file name and the back link file (it should point to the directory).

Was that the current sys$share:debug.exe or maybe it was a remaining of some VMS upgrade?

Bojan

Wim Van den Wyngaert · ‎10-04-2004

Yes it was sys$share. Maybe the name wasn't given because the file was corrupt ?
I will keep an eye on it.

Wim

Wim

Uwe Zessin · ‎10-04-2004

Hm...
Sorry, but that does not sound plausible to me. We're talking about corruption _inside_ a file, not in the file system's structure. If the file is properly linked from a directory I think the full path should be displayed to make the whole handling easy for the user.

.

faris_3 · ‎10-04-2004

Hi,

You may try to check if you have a problem
on the free blocks now.

Fill the disk

$ copy nl: tempfile /alloc=free_blocks_on_disk

$ set file /end tempfile

$analyze /disk/read ...

hth,
HF

Wim Van den Wyngaert · ‎10-04-2004

Uwe,

I don't know how the program is written but may be it doesn't always do the effort for looking for the file name after a parity error.

Farris,

Did somethink like that. No extra bad blocks.

All,

Maybe the disk should have been filled in the farris way before the OS was installed. Or maybe we should have used some kind of read check option during install.

Wim

Wim

Ian Miller. · ‎10-05-2004

when the bad debug.exe was deleted then any bad blocks would have been transparently revectored so when the disk was filled with the temp file and all blocks read then no bad blocks where found.

____________________
Purely Personal Opinion

faris_3 · ‎10-05-2004

Or put in badblk.sys depending on the controller type :

See
[OpenVMS] How are Bad Block Handled on SCSI Disk Devices?

http://h18000.www1.hp.com/support/asktima/operating_systems/009370EE-0A09ACC0-1C009F.html

Wim Van den Wyngaert · ‎10-28-2004

Rather strange findings.

VMS 7.3 on AStation 500.

Do type of file : parity error.
Defragmenter : aborts when it tries to defragment the file.
Dia reports "MEDIUM ERROR".

ana/dis/read : reports nothing !!!

If I do delete/erase of the file another file created after the delete gets corrupted.

So : bad blocks are not always handled correctly.

I renamed the last corrupted file to .badblocks and marked it with set file/nomov. Defragmenter is now happy. This seems the only working solution.

Wim

Wim

Uwe Zessin · ‎10-28-2004

You could also set it to /NOBACKUP so that its contents are not read during backups.

.

Vladimir K. Vershinin · ‎10-28-2004

And BACKUP and RESTORE disk contents.

Vladimir Vershinin