- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Anal/dis/rep/read
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
тАО10-03-2004 08:59 PM
тАО10-03-2004 08:59 PM
Re: Anal/dis/rep/read
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-03-2004 11:23 PM
тАО10-03-2004 11:23 PM
Re: Anal/dis/rep/read
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-03-2004 11:25 PM
тАО10-03-2004 11:25 PM
Re: Anal/dis/rep/read
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-03-2004 11:27 PM
тАО10-03-2004 11:27 PM
Re: Anal/dis/rep/read
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-03-2004 11:36 PM
тАО10-03-2004 11:36 PM
Re: Anal/dis/rep/read
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2004 03:40 AM
тАО10-04-2004 03:40 AM
Re: Anal/dis/rep/read
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2004 06:04 AM
тАО10-04-2004 06:04 AM
Re: Anal/dis/rep/read
I will keep an eye on it.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2004 06:13 AM
тАО10-04-2004 06:13 AM
Re: Anal/dis/rep/read
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2004 09:27 PM
тАО10-04-2004 09:27 PM
Re: Anal/dis/rep/read
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-04-2004 10:06 PM
тАО10-04-2004 10:06 PM
Re: Anal/dis/rep/read
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