- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: DFU-E-MISMATCH error in trying to defrag INDEX...
Operating System - OpenVMS
1747986
Members
4696
Online
108756
Solutions
Forums
Categories
Company
Local Language
юдл
back
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
юдл
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- 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
тАО12-07-2008 04:17 AM
тАО12-07-2008 04:17 AM
Re: DFU-E-MISMATCH error in trying to defrag INDEXF.SYS
Edgar,
Note that when you tried to defrag before, it was trying to create a new mapping pointer with 4456448 blocks, and that is 68*65536. Since you now have 9156448 blocks that can be defragmented, and that isn't a multiple of 65536 (since you extended by a non-multiple of 65536), my guess is that the defrag will now work.
So until a version of DFU with this problem fixed is released, if dfu indexf /analyze shows that it will try to consolidate a multiple of 65536 blocks, and the disk has room for another retrieval pointer, then a work around is to use the indexf /extend to extend by 1 block (it will be rounded up to the next cluster), and then defrag.
Jon
p.s. I really meant to type meant instead of menat.
Note that when you tried to defrag before, it was trying to create a new mapping pointer with 4456448 blocks, and that is 68*65536. Since you now have 9156448 blocks that can be defragmented, and that isn't a multiple of 65536 (since you extended by a non-multiple of 65536), my guess is that the defrag will now work.
So until a version of DFU with this problem fixed is released, if dfu indexf /analyze shows that it will try to consolidate a multiple of 65536 blocks, and the disk has room for another retrieval pointer, then a work around is to use the indexf /extend to extend by 1 block (it will be rounded up to the next cluster), and then defrag.
Jon
p.s. I really meant to type meant instead of menat.
it depends
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-08-2008 01:55 AM
тАО12-08-2008 01:55 AM
Re: DFU-E-MISMATCH error in trying to defrag INDEXF.SYS
Edgar,
One other possible work around is to use the dfu indexf /truncate function to truncate the indexf.sys file to its current EOF possition. As long as that won't result in the last retrieval pointer mapping a multiple of 65536 blocks, that should work. Then you could defrag, or if you want to extend by less than the amount you had extended before, you can extend by an amount that isn't a multiple of 65536. Then you can defrag. If the defrag fails, then extend by one more block(cluster) and then defrag.
The problem appears to affect only creation of a format 3 retrieval pointer that maps a multiple of 65536 blocks; once they are created, DFU can interpret them correctly. The problem stems from the fact that retrieval pointers store the count as n-1, since all retrieval points that map blocks will always map at least one cluster, the value 0 in a retrieval pointer's count field maps 1 block. Likewise, the value 0xFFFF maps 65536 blocks, not 65535. There are four formats for retrieval pointers, and they are all a different size. The format is always stored in bits 14:15 of the first word of the retrieval pointer. In format 3, the 30 bit count is split into two fields; the Least Significant 16 bits is in the second word, and the Most Significant 14 bits are in the first 14 bits of the first word. The computation of the value to store is done incorrectly iff the count is a multiple of 65536.
Example from the hex dump of the file header in attachment, if you are interested in the details.
If you have VMS File System Internals by Kirby McCoy (1990), the retrieval pointer formats are described on pages 33-37.
Jon
One other possible work around is to use the dfu indexf /truncate function to truncate the indexf.sys file to its current EOF possition. As long as that won't result in the last retrieval pointer mapping a multiple of 65536 blocks, that should work. Then you could defrag, or if you want to extend by less than the amount you had extended before, you can extend by an amount that isn't a multiple of 65536. Then you can defrag. If the defrag fails, then extend by one more block(cluster) and then defrag.
The problem appears to affect only creation of a format 3 retrieval pointer that maps a multiple of 65536 blocks; once they are created, DFU can interpret them correctly. The problem stems from the fact that retrieval pointers store the count as n-1, since all retrieval points that map blocks will always map at least one cluster, the value 0 in a retrieval pointer's count field maps 1 block. Likewise, the value 0xFFFF maps 65536 blocks, not 65535. There are four formats for retrieval pointers, and they are all a different size. The format is always stored in bits 14:15 of the first word of the retrieval pointer. In format 3, the 30 bit count is split into two fields; the Least Significant 16 bits is in the second word, and the Most Significant 14 bits are in the first 14 bits of the first word. The computation of the value to store is done incorrectly iff the count is a multiple of 65536.
Example from the hex dump of the file header in attachment, if you are interested in the details.
If you have VMS File System Internals by Kirby McCoy (1990), the retrieval pointer formats are described on pages 33-37.
Jon
it depends
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-09-2008 05:16 AM
тАО12-09-2008 05:16 AM
Re: DFU-E-MISMATCH error in trying to defrag INDEXF.SYS
Appreciate all the work you put into this, Jon. I had to defragment the disk with HP DFG last weekend (because the weekly job that dumps thousands of files onto the disk was about to run) so I will no longer be able to try any more DFU commands on it.
And yes, I have McCoy's book buried somewhere. I'll have to dig it up.
Thanks again!
And yes, I have McCoy's book buried somewhere. I'll have to dig it up.
Thanks again!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-09-2008 03:30 PM
тАО12-09-2008 03:30 PM
Re: DFU-E-MISMATCH error in trying to defrag INDEXF.SYS
Summary for future searchers:
The error message:
%DFU-E-MISMATCH, Error in new mapping pointers
is printed when DFU finds the number of LBNs mapped by the newly created in memory candidate file header for INDEXF.SYS is in disagreement with the existing file header. When this inconsistency is found, the candidate header is not used to replace the file header, and things are left as they were found.
Cause:
DFU at least through V3.2 has an error in the way it creates format 3 retrieval pointers that map a multiple of 65536 blocks. The effect is that they map 65536 blocks more than they should. This can be seen if the /show_pointers qualifier is used with the dfu indexf /defrag command.
This is exacerbated by the following factors:
1. The XQP likes to extend by 131072 blocks, a multiple of 65536 blocks.
2. Extended BITMAP support results in many more disks with a cluster factor of 8 or 16, therefore an extension of 131072 will not be rounded up to the next cluster boundary.
3. The fact that DFU defrag consolidates only the retrieval pointers that were not created at the time the disk was initialized. This makes it more likely that a disk├в s indexf.sys file will have been extended in total by a multiple of 65536 blocks.
Work around:
The next version of DFU after 3.2 will be fixed.
DFO 3.0 works but is not free.
In the mean time, if DFU 3.2 is what you have to work with, and there is enough remaining space in the mapping area for an additional retrieval pointer, then you can extend by 1 cluster, and then you should be able to defrag.
Example work around with DFU 3.2
$ define dfu$nosmg 1
$ mcr dfu indexf /analyze /show_pointers disk:
if this shows that the amount that can be defragmented IS NOT a multiple of 65536, then the bug should not affect you, and you should be able to defrag the indexf.sys file
$ mcr dfu indexf /defrag /show_pointers disk:
Else if analyze shows that the amount that can be defragmented IS a multiple of 65536, and there is sufficient space for an additional mapping pointer, do the following:
$ mcr dfu indexf /extend=1 /show_pointers disk:
Then start from the /analyze point above.
If there is not enough room for an additional mapping pointer, you may be able to truncate the indexf.sys file, although if you have gotten to this point due to the XQP extending the file, then it is unlikely that this will work. You can try.
$ mcr dfu indexf /truncate /show_pointers disk:
If that works, go to analyze above.
If that does not work, and neither DFU > v3.2 or DFO is an option, then an image backup to another disk is your option.
Jon
The error message:
%DFU-E-MISMATCH, Error in new mapping pointers
is printed when DFU finds the number of LBNs mapped by the newly created in memory candidate file header for INDEXF.SYS is in disagreement with the existing file header. When this inconsistency is found, the candidate header is not used to replace the file header, and things are left as they were found.
Cause:
DFU at least through V3.2 has an error in the way it creates format 3 retrieval pointers that map a multiple of 65536 blocks. The effect is that they map 65536 blocks more than they should. This can be seen if the /show_pointers qualifier is used with the dfu indexf /defrag command.
This is exacerbated by the following factors:
1. The XQP likes to extend by 131072 blocks, a multiple of 65536 blocks.
2. Extended BITMAP support results in many more disks with a cluster factor of 8 or 16, therefore an extension of 131072 will not be rounded up to the next cluster boundary.
3. The fact that DFU defrag consolidates only the retrieval pointers that were not created at the time the disk was initialized. This makes it more likely that a disk├в s indexf.sys file will have been extended in total by a multiple of 65536 blocks.
Work around:
The next version of DFU after 3.2 will be fixed.
DFO 3.0 works but is not free.
In the mean time, if DFU 3.2 is what you have to work with, and there is enough remaining space in the mapping area for an additional retrieval pointer, then you can extend by 1 cluster, and then you should be able to defrag.
Example work around with DFU 3.2
$ define dfu$nosmg 1
$ mcr dfu indexf /analyze /show_pointers disk:
if this shows that the amount that can be defragmented IS NOT a multiple of 65536, then the bug should not affect you, and you should be able to defrag the indexf.sys file
$ mcr dfu indexf /defrag /show_pointers disk:
Else if analyze shows that the amount that can be defragmented IS a multiple of 65536, and there is sufficient space for an additional mapping pointer, do the following:
$ mcr dfu indexf /extend=1 /show_pointers disk:
Then start from the /analyze point above.
If there is not enough room for an additional mapping pointer, you may be able to truncate the indexf.sys file, although if you have gotten to this point due to the XQP extending the file, then it is unlikely that this will work. You can try.
$ mcr dfu indexf /truncate /show_pointers disk:
If that works, go to analyze above.
If that does not work, and neither DFU > v3.2 or DFO is an option, then an image backup to another disk is your option.
Jon
it depends
- « Previous
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP