- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Disk showing file+size but type results in fil...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2007 07:58 PM
тАО09-03-2007 07:58 PM
Disk showing file+size but type results in file not found
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2007 08:59 PM
тАО09-03-2007 08:59 PM
Re: Disk showing file+size but type results in file not found
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2007 10:50 PM
тАО09-03-2007 10:50 PM
Re: Disk showing file+size but type results in file not found
regards kalle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2007 11:36 PM
тАО09-03-2007 11:36 PM
Re: Disk showing file+size but type results in file not found
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=
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2007 12:15 AM
тАО09-04-2007 12:15 AM
Re: Disk showing file+size but type results in file not found
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2007 01:08 AM
тАО09-04-2007 01:08 AM
Re: Disk showing file+size but type results in file not found
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2007 10:51 AM
тАО09-04-2007 10:51 AM
Re: Disk showing file+size but type results in file not found
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2007 12:25 PM
тАО09-04-2007 12:25 PM
Re: Disk showing file+size but type results in file not found
$ TYPE/PAGE bhr_save:secur*.*
I'd also look at DIR/FULL to see if ther are any clues there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-05-2007 06:32 PM
тАО09-05-2007 06:32 PM
Re: Disk showing file+size but type results in file not found
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-05-2007 08:00 PM
тАО09-05-2007 08:00 PM
Re: Disk showing file+size but type results in file not found
I have a search list on 3 disks (a concealed device) and it behaves normally.
Wim