Operating System - OpenVMS
1747986 Members
4696 Online
108756 Solutions
New Discussion юеВ

Re: DFU-E-MISMATCH error in trying to defrag INDEXF.SYS

 
SOLVED
Go to solution
Jon Pinkley
Honored Contributor

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.
it depends
Jon Pinkley
Honored Contributor

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
it depends
EdgarZamora_1
Respected Contributor

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!
Jon Pinkley
Honored Contributor

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
it depends