Disk showing file+size but type results in file not found

[Midrange-EB]

Hello,

after an error on one of the shadowmembers the disk started behaving perculiar.

For example when I do a dir listing it shows:

$ dir bhr_save:secur*

Directory BHR_ROOT:[SAVE]

SECURITY.20070830;1 26/36 31-AUG-2007 00:31:00.62

However when I would like to type or edit it produces:

$ type bhr_save:SECURITY.20070830
%TYPE-W-SEARCHFAIL, error searching for BHR_ROOT:[SAVE]SECURITY.20070830;
-RMS-E-FNF, file not found

An analyze/disk/repair doesn't help so I guess I'm out options and thus restoring a backup would be the only way out, or am I overlooking something?

Thanks!

[Heinz W Genhart]

Hi Midrange-EB

first of all, Welcome to the ITRC OpenVMS forum.

What Version of OpenVMS ist this?

Is your problem disk a ODS-2 or an ODS-5 Disk?
(SHOW DEVICE/FULL disk)

If this disk is a ODS-5 Disk, did you a
$SET PROCESS /PARSE_STYLE=EXTENDED ?

Regards

Geni

[Karl Rohwedder]

How is the logical bhr_root defined (sh log/fu bhr_root)?

regards kalle

[Hein van den Heuvel]

Geni,
There's nothing extended or ods-5-ish about the file name it there now?

Kalle,
It seems that 'bhr_root' can be used just fine for Directory no?

Midrange-EB,
If DIRECTORY can display the size, then the file name in the directory, leads to the file-header (through the file-id) where the size is kept. For there it is only a small step to the actual data: read the mapping pointer in that same header, and follow that to the data.
Could the file have an EXTENTION header which can not be found? That's unlikely because there are at most two entries needed as 26/36 suggests a cluster size of either 18 or 36.

Anyway, you should DUMP/HEADER/BLOCK=COUNT=1 for the next step of the investigation. Post the results here (in an attachment as a text file if that dump works).
Look at the FILE-ID (dir/fi).
Now try a DUMP/HEAD memberX:/ID=id-part for both members. Header the same?
Now figure out the LBN for the header (combine ID, Cluster-size, Max-files) and $DUMP/BLOC=(COUN=1,STA=) memberX:.
DO that for each member and compare the bits.. they should be the same.

>>> after an error on one of the shadowmembers the disk started behaving perculiar

Host-based? - what OpenVMS version/patched?
Controller based? Which controller? Version?

Anyway what was done after the error? Did the shadowing reject the drive? Was the disk reporting errors replaced?

It is not unheard of that a shadow set for which a member went bad gives 'unexplainable' results because the members are out of sync.
I'd like to think that the shadowing resolves that, but unfortunately judging by the data alone shadowing can not on its own decide what is good, what bad. It may seem obvious to us, but a 'bad' result may be the correct data as far as the system is concerned (unlikely though!).

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Midrange-EB]

Thanks for your replies.

All this is on VMS 7.3.2
ODS-2
HSZ-80 controller/cabinet

A dump of the header also leads to a file not found message.

I will dig some deeper tomorrow.

Thanks so far.
Jeroen.

[Hein van den Heuvel]

Jeroen,

Maybe the DIR/SIZE info was still coming from the system caches. Is that still working, or does that also give FNF?

Here is a little script to dump the raw 'supposed' file header as VBN from INDEXF.SYS. It implements the algoritme needed which I hinted to above.

Use black bible 'VMS File systems internals' or SYS$LIBRARY:LIB.MLB to decode :-).

Met vriendelijke groetjes,
Hein.



$ type DUMP_FILE_HEADER.COM
$!
$! read_file_header.com Hein van den Heuvel, Sep-2007
$!
$! This command file dumps the header for a file, from INDEXF.SYS using the file-id.
$! Next step might be to not translate that to an LBN to be able to directly read it from an unmounted (shadow) copy.
$!
$!
$! Enjoy!
$! Hein
$! HvdH Performance Consulting
$
$!
$! 1) Get file id from directory commands
$! F$file(file,"FID") might get 'locked' or 'file-not-found' error)
$!
$if p1.eqs."" then inquire p1 "file name"
$dir/file/out=tmp.tmp/notrail/nohead/wid=file=1 'p1
$open/read tmp tmp.tmp
$read tmp tmp
$read tmp tmp
$clos tmp
$dele tmp.tmp.
$id = f$elem(0,",",f$elem(1,"(",tmp))
$
$!
$! 2) Use file Id to look up file corresponding file header in INDEXF.SYS
$!
$dev = f$parse(p1,,,"device")
$!
$! The file-ID is an offest into INDEXF.SYS
$! INDEX.SYS first starts out with 4 cluster, and then
$! a bitmap to hold a bit for each potential file header.
$! And as for every VBN, the count starts at # 1.
$!
$indexf_bitmap_vbn = (f$getdvi(dev,"cluster") * 4) + 1
$ibmapsize = (f$getdvi(dev,"maxfiles") + 4095) / 4096
$header_vbn = indexf_bitmap_vbn + ibmapsize + id -1
$dump/block=(count=1,start='header_vbn') 'dev'[000000]indexf.sys
$exit

[Thomas Ritter]

EB,
Are the results the same when you

$ type bhr_root:[save]security.20070830
And
$ type bhr_save:security.20070830

If you get the chance would you run

$ anal/disk/repair/lock â diskâ

And post the results.

[John Gillings]

Wildcards can sometimes help work out what's missing. Try

$ TYPE/PAGE bhr_save:secur*.*

I'd also look at DIR/FULL to see if ther are any clues there.

[Willem Grooters]

This rings a bell, I've seen this before, and IIRC, my investigation at the time lead to the following conclusion:

If a concealed logical (read: logical device) is a searchlist of one directory over multiple physical disks, and the file is on the second-mentioned disk, DIR will find it but direct acccess to the file will fail.
Accessing the file EXPLICTLY by the real location (so the second path in the list) will allow you to access the file.

This happened because the physical disk on which the second entry in this serachlist was full and the directory was kind of 'extended' on the other disk using a searchlist.

Example:
BHR_ROOT was DISK1:[BHR.](conc), contains a directory [SAVE] where your file (SECURITY.20070830;1 resides.
Now you change BHR_ROOT to be:
DISk2:[BHR.](conc), DISK1:[BHR.](conc), and on DISK2:[BHR] you create a [SAVE] directory to store new files.
DIR BHR_ROOT:[SAVE] will show up your file, but TYPE will fail to get it. if you access the file by it's real directory DISK2:[BHR.SAVE], you'll get it.

The problem was solved by relocation the whole directory from the full disk to the empty one, thereby removing the split over devices of that directory.

[Wim Van den Wyngaert]

Willem,

I have a search list on 3 disks (a concealed device) and it behaves normally.

Wim

[Jan van den Ende]

I have to concur with Wim.

I have never found the issue Willem reports, and we have had several of such construct: it was part of the mechanism of moving all our drives from HSZ-connected to SAN drives!

Proost.

Have one on me.

jpe

[Willem Grooters]

Wim, Jan,

I was very surprised as well - but it was just what I found and how I could get around it.
I just noticed that it propably not BHR_ROOT as a searchlist, but BHR_SAVE. That might just make the difference...

I wonder what $ SHO LOG/FULL BHR_SAVE will return.

[Hein van den Heuvel]

Willem wrote:

>> This happened because the physical disk on which the second entry in this serachlist was full and the directory was kind of 'extended' on the other disk using a searchlist.


Willem, so the error was NOT the FNF reported by some _FUL error?

The normal behaviour for a search list is to allow you to find an existing file using any entry. File will be created on the first entry.
The biggest (only) surprise with search list is that commands which have an 'related file context' can combine parts of the specs in the searchlist.


I experienced a yet to be fully explained FNF myself last night:

$backup/igno=inter source desct
%BACKUP-E-READATTR, error reading attributes for SOURCE_DEV:[SOURCE_DIR]SOURCE-SYSTEM-W-NOSUCHFILE, no such file
%BACKUP-W-READATTRRETRY, 1 READATTR error occurred reading SOURCE_DEV:[SOURCE_DIR]SOURCE
%BACKUP-E-VBNMISSING, SOURCE_DEV:[SOURCE_DIR]SOURCE has missing block
s 12092353 through 12412032

For now I am blaming that on the /igno=inter and the file having many headers, one possibly actively changing.
Retry worked for me.

Hein

[Richard W Hunt]

I've not seen this before.

Is there a chance that the BHR_SAVE volume is actually a multi-disk bound volume for which the directory and header are on one disk but the second part of the volume is out of touch, part of the damage caused by the shadow incident?

Has the system rebooted since this error was seen and does the volume in question go into Mount Verification for an inordinately long time? When you look at the drive status right after a reboot, do you see "Shadow Merge" or "Shadow Copy" events? (Indicating a disparity between shadow master and shadow member IIRC)