Operating System - OpenVMS
1748112 Members
3346 Online
108758 Solutions
New Discussion юеВ

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

 
SOLVED
Go to solution
EdgarZamora_1
Respected Contributor

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

Sorry for the delayed response... long holiday weekend.

I was able to use HP's DFG 3.0 to defragment the INDEXF.SYS successfully.

Jess, the volume did not get corrupted by the DFU error... it remained the same (thank God).

Volker, I had actually used DFU on this same volume (and a couple of others) about a year ago to defragment the INDEXF.SYS successfully, so I know DFU does successfully defragment the INDEXF.SYS in most cases. I guess this volume is just getting bigger and bigger (thousands of archive files are being dumped into it) and I may have hit some limit on DFU.

Hein, thanks for that great tool you attached! I'm looking at it as it looks to be most useful.

Jur, I'm sorry I didn't see these responses before I ran DFG on the disk. The indexf is defragmented now. I won't be able to supply the debug info you requested.

Thank you all for the responses!
Jur van der Burg
Respected Contributor

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

>Jess, the volume did not get corrupted by the >DFU error... it remained the same (thank God).

DFU defrgaments indexf.sys by copying it to a new contiguous location found on disk. After the copy it found some issues, and did not update the rest, so only a piece of free space was overwritten. Call it the 'safe approach'.

Jur.
EdgarZamora_1
Respected Contributor

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

Jur,

As it turns out, I found a similar volume that exhibited the same problem when I tried using DFU to defrag the indexf.sys. I collected the info you asked for and I'm attaching to this reply. I will hold off defragging the indexf with HP DFG in case you want some other info. Thanks!
Jon Pinkley
Honored Contributor

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

Edgar,

I can't see anything obviously wrong, and I don't understand why this problem is happening. I have used this feature on volumes that have "used up" the mapping area, so it is something other than the number of fragments that is causing the problem. I have never defragged an indexf.sys file that had such large extents, so that may be a contributing factor.

Can you also provide the output of the following:

$ define dfu$nosmg 1
$ mcr dfu report/graph $1$dga925: ! more volume related info
$ show device/full $1$dga925: ! this will show total blocks and logical volume size
$ dump/count=1 $1$dga925:[000000]bitmap.sys ! Storage Control Block (SCB)

-----

To determine why DFU is reporting

%DFU-E-MISMATCH, Error in new mapping pointers

is probably going to require a change to the source code of DFU so it gives a better hint as to why it thought there was an error, i.e. what it was expecting and what it found.

Jon
it depends
Jon Pinkley
Honored Contributor

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

The last command to dump the SCB should be:

$ dump/block=count=1 $1$dga925:[000000]bitmap.sys

not

$ dump/count=1 $1$dga925:[000000]bitmap.sys
it depends
EdgarZamora_1
Respected Contributor

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

Jon, thanks for spending some time on this. Here's the info you asked for.
Jon Pinkley
Honored Contributor

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

Edgar,

I see an unrelated bug in the output of DFU's /graph output, where it is evidently overflowing in the calculation of starting LBN. This works correctly on my 120GB disk (and I expect it to work correctly on any disk with logical volume size <= 153391689 blocks). In addition to the calculation being incorrect, the output field for LBN is too small for large disks. That may get fixed if another version ever gets released.

However, that is cosmetic and not related to this problem.

It would be interesting to see if it is possible to use the DFU INDEXF /EXTEND=xxx command, or if that results in the same problem. Since you have used about half the disk, you could just double what you currently have and use only one extent. For example:

$ mcr dfu indexf /extend=4700000 $1$DGA925:

Jon
it depends
EdgarZamora_1
Respected Contributor

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

Jon, the /EXTEND worked...

$ mcr dfu indexf /extend=4700000 $1$DGA925:

Disk and File Utilities for OpenVMS V3.2
%DFU-I-MOUNTING, Busy mounting disk $1$DGA925:...
%DFU-I-ANALDISK, Analyzing INDEXF and BITMAP...
%DFU-I-TOTAL, Maparea maps 4760560 blocks in 38 fragments (94% used)
%DFU-I-FINDLBN, Largest free contiguous space 617758680 blocks at LBN 577326120
%DFU-I-EXTEND, INDEXF.SYS can be extended with 4700000 blocks
Continue to modify INDEXF.SYS ? (Y/N) [N] : y
%DFU-I-MOUNTFOR, Busy remounting disk $1$DGA925: /FOREIGN...
%DFU-I-NEWTOTAL, New Maparea maps 9460560 blocks in 39 fragments
%DFU-S-REWRTIF, INDEXF.SYS File header rewritten !
%DFU-I-RBDBITMAP, Updating BITMAP.SYS...
%DFU-S-DONE, all operations succesfully completed

%DFU-I-DISMNT, Volume dismounted

%DFU-I-READY, INDEXF command ready
$ mount/over=id $1$dga925:
%MOUNT-I-MOUNTED, ARCHIVE3 mounted on _$1$DGA925: (CLCC)
$ def dfu$nosmg 1
$ mcr dfu indexf /anal $1$dga925:

Disk and File Utilities for OpenVMS V3.2
%DFU-I-ANALDISK, Analyzing INDEXF and BITMAP...
%DFU-I-MAPPTR, Retrieval ptr ( 1) Size : 16 , LBN : 0
%DFU-I-MAPPTR, Retrieval ptr ( 2) Size : 8 , LBN : 1032
%DFU-I-MAPPTR, Retrieval ptr ( 3) Size : 8 , LBN : 370656
%DFU-I-MAPPTR, Retrieval ptr ( 4) Size : 304080 , LBN : 66576
%DFU-I-MAPPTR, Retrieval ptr ( 5) Size : 131072 , LBN :38346104
%DFU-I-MAPPTR, Retrieval ptr ( 6) Size : 131072 , LBN :63176120
%DFU-I-MAPPTR, Retrieval ptr ( 7) Size : 131072 , LBN :79053280
%DFU-I-MAPPTR, Retrieval ptr ( 8) Size : 131072 , LBN :107558728
%DFU-I-MAPPTR, Retrieval ptr ( 9) Size : 131072 , LBN :120191128
%DFU-I-MAPPTR, Retrieval ptr (10) Size : 131072 , LBN :133670072
%DFU-I-MAPPTR, Retrieval ptr (11) Size : 131072 , LBN :146541056
%DFU-I-MAPPTR, Retrieval ptr (12) Size : 131072 , LBN :159403536
%DFU-I-MAPPTR, Retrieval ptr (13) Size : 131072 , LBN :173544616
%DFU-I-MAPPTR, Retrieval ptr (14) Size : 131072 , LBN :207464576
%DFU-I-MAPPTR, Retrieval ptr (15) Size : 131072 , LBN :241281928
%DFU-I-MAPPTR, Retrieval ptr (16) Size : 131072 , LBN :258080104
%DFU-I-MAPPTR, Retrieval ptr (17) Size : 131072 , LBN :274775344
%DFU-I-MAPPTR, Retrieval ptr (18) Size : 131072 , LBN :214126040
%DFU-I-MAPPTR, Retrieval ptr (19) Size : 131072 , LBN :291149168
%DFU-I-MAPPTR, Retrieval ptr (20) Size : 131072 , LBN :307298640
%DFU-I-MAPPTR, Retrieval ptr (21) Size : 131072 , LBN :324895312
%DFU-I-MAPPTR, Retrieval ptr (22) Size : 131072 , LBN :341005752
%DFU-I-MAPPTR, Retrieval ptr (23) Size : 131072 , LBN :357158328
%DFU-I-MAPPTR, Retrieval ptr (24) Size : 131072 , LBN :372325304
%DFU-I-MAPPTR, Retrieval ptr (25) Size : 131072 , LBN :386814152
%DFU-I-MAPPTR, Retrieval ptr (26) Size : 131072 , LBN :403266872
%DFU-I-MAPPTR, Retrieval ptr (27) Size : 131072 , LBN :419210080
%DFU-I-MAPPTR, Retrieval ptr (28) Size : 131072 , LBN :493705864
%DFU-I-MAPPTR, Retrieval ptr (29) Size : 131072 , LBN :509799296
%DFU-I-MAPPTR, Retrieval ptr (30) Size : 131072 , LBN :525271840
%DFU-I-MAPPTR, Retrieval ptr (31) Size : 131072 , LBN :437381128
%DFU-I-MAPPTR, Retrieval ptr (32) Size : 131072 , LBN :454103432
%DFU-I-MAPPTR, Retrieval ptr (33) Size : 131072 , LBN :468584160
%DFU-I-MAPPTR, Retrieval ptr (34) Size : 131072 , LBN :545502912
%DFU-I-MAPPTR, Retrieval ptr (35) Size : 131072 , LBN :559213368
%DFU-I-MAPPTR, Retrieval ptr (36) Size : 131072 , LBN :570764696
%DFU-I-MAPPTR, Retrieval ptr (37) Size : 131072 , LBN :477588064
%DFU-I-MAPPTR, Retrieval ptr (38) Size : 131072 , LBN :487445880
%DFU-I-MAPPTR, Retrieval ptr (39) Size : 4700000 , LBN :577326120
%DFU-I-TOTAL, Maparea maps 9460560 blocks in 39 fragments (96% used)
%DFU-I-FINDLBN, Largest free contiguous space 613058680 blocks at LBN 582026120
%DFU-I-MOVE, 9156448 blocks can be defragmented (35 fragments)

%DFU-I-READY, INDEXF command ready
$


I will probably use HP DFG to defragment the INDEXF.SYS today anyway. It's good to know about the extend though. Thanks!
Jon Pinkley
Honored Contributor

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

Edgar,

I haven't determined what the cause is, but I was able to reproduce the problem. It seems that DFU doesn't like mapping pointers that map a multiple of 65536 (2^16) blocks. 131072=2*65536=2^17. DFU will not let me extend by either 65536 or 131072. The disk I was playing with was a snapclone of a 120GB drive, and currently is somewhat fragmented, so there wasn't enough space to extend by 3*65536.

There is an additional switch to DFU that can be used with the INDEXF operations, /show_pointers. The help suggests that it works only with /analyze, but it appears to work with /extend and /defrag. When I try to extend by a multiple of 65536, the reported pointer size is 65536 more than what was requested, so the sanity check fails. Following are examples for 65536 and 131072. Note that the new mapping pointer is 65536 blocks larger than it should be.

$ dfu indexf /exte=65536 /show $1$dga2401

Disk and File Utilities for OpenVMS V3.2
%DFU-I-MOUNTING, Busy mounting disk $1$DGA2401:...
%DFU-I-ANALDISK, Analyzing INDEXF and BITMAP...
%DFU-I-MAPPTR, Retrieval ptr ( 1) Size : 32 , LBN : 0
%DFU-I-MAPPTR, Retrieval ptr ( 2) Size : 16 , LBN : 1024
%DFU-I-MAPPTR, Retrieval ptr ( 3) Size : 16 , LBN : 38912
%DFU-I-MAPPTR, Retrieval ptr ( 4) Size : 5088 , LBN : 33824
%DFU-I-MAPPTR, Retrieval ptr ( 5) Size : 131152 , LBN :198826400
%DFU-I-TOTAL, Maparea maps 136304 blocks in 5 fragments (8% used)
%DFU-I-FINDLBN, Largest free contiguous space 132896 blocks at LBN 188392224
%DFU-I-EXTEND, INDEXF.SYS can be extended with 65536 blocks
Continue to modify INDEXF.SYS ? (Y/N) [N] : y
%DFU-I-MOUNTFOR, Busy remounting disk $1$DGA2401: /FOREIGN...
%DFU-I-MAPPTR, Retrieval ptr size 32 LBN 0
%DFU-I-MAPPTR, Retrieval ptr size 16 LBN 1024
%DFU-I-MAPPTR, Retrieval ptr size 16 LBN 38912
%DFU-I-MAPPTR, Retrieval ptr size 5088 LBN 33824
%DFU-I-MAPPTR, Retrieval ptr size 131152 LBN 198826400
%DFU-I-MAPPTR, Retrieval ptr size 131072 LBN 188392224
%DFU-E-MISMATCH, Error in new mapping pointers
%DFU-I-DISMNT, Volume dismounted

%DFU-I-READY, INDEXF command ready
$ dfu indexf /exte=131072/show $1$dga2401

Disk and File Utilities for OpenVMS V3.2
%DFU-I-MOUNTING, Busy mounting disk $1$DGA2401:...
%DFU-I-ANALDISK, Analyzing INDEXF and BITMAP...
%DFU-I-MAPPTR, Retrieval ptr ( 1) Size : 32 , LBN : 0
%DFU-I-MAPPTR, Retrieval ptr ( 2) Size : 16 , LBN : 1024
%DFU-I-MAPPTR, Retrieval ptr ( 3) Size : 16 , LBN : 38912
%DFU-I-MAPPTR, Retrieval ptr ( 4) Size : 5088 , LBN : 33824
%DFU-I-MAPPTR, Retrieval ptr ( 5) Size : 131152 , LBN :198826400
%DFU-I-TOTAL, Maparea maps 136304 blocks in 5 fragments (8% used)
%DFU-I-FINDLBN, Largest free contiguous space 132896 blocks at LBN 188392224
%DFU-I-EXTEND, INDEXF.SYS can be extended with 131072 blocks
Continue to modify INDEXF.SYS ? (Y/N) [N] : y
%DFU-I-MOUNTFOR, Busy remounting disk $1$DGA2401: /FOREIGN...
%DFU-I-MAPPTR, Retrieval ptr size 32 LBN 0
%DFU-I-MAPPTR, Retrieval ptr size 16 LBN 1024
%DFU-I-MAPPTR, Retrieval ptr size 16 LBN 38912
%DFU-I-MAPPTR, Retrieval ptr size 5088 LBN 33824
%DFU-I-MAPPTR, Retrieval ptr size 131152 LBN 198826400
%DFU-I-MAPPTR, Retrieval ptr size 196608 LBN 188392224
%DFU-E-MISMATCH, Error in new mapping pointers
%DFU-I-DISMNT, Volume dismounted

%DFU-I-READY, INDEXF command ready
$

Since the XQP likes to extend by 2^17 blocks, this probably affects a large number of disks that need to have their indexf.sys file defragmented.

Can you possibly try defragmenting again while using the /show_pointers qualifier? The defrag will not work, but it hopefully will provide some additional info that will help narrow the problem.

$ define dfu$nosmg 1
$ mcr dfu /defrag /show_pointers $1$DGA925:

Jon
it depends
Jon Pinkley
Honored Contributor

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

Edgar,

What I menat was

$ define dfu$nosmg 1
$ mcr dfu INDEXF /defrag /show_pointers $1$DGA925:

Jon
it depends