Unsolved
This post is more than 5 years old
56 Posts
0
1096
June 10th, 2008 04:00
Invalid Track counts in new Dynamic SRDF pairs
I have a question about the numbers I see in a "symrdf query" command. The situation is as follows:
- New metadevices were formed, consisting of 1 header and 15 members each. The same amount of meta's were formed on the R1 box as on the R2 box.
- The meta's are Dynamic Capable and were added to an empty Dynamic RDF group, using "createpair -invalidate R2 -type R1".
- The pairs were then put in ACP Disk mode using "set mode acp_disk", and a "symrdf establish" command was given.
This all works fine, data was flowing from the R1 to the R2 as you would expect. However, the output of a query shows the following:
Symmetrix ID : 000xxxxxxxxx
Remote Symmetrix ID : 000xxxxxxxxx
RDF (RA) Group Number : 42 (29)
Source (R1) View Target (R2) View MODES
-------------------------------- ------------------------ ----- ------------
ST LI ST
Standard A N A
Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair
Device Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE
-------------------------------- -- ------------------------ ----- ------------
N/A 00EC RW 0 6405130 NR 00EC WD 0 0 C.D Suspended
N/A 00FC RW 0 5891534 NR 00FC WD 0 0 C.D Suspended
N/A 010C RW 0 6623350 NR 010C WD 0 0 C.D Suspended
N/A 011C RW 0 6898842 NR 011C WD 0 0 C.D Suspended
N/A 012C RW 0 6776868 NR 012C WD 0 0 C.D Suspended
N/A 013C RW 0 6593114 NR 013C WD 0 0 C.D Suspended
N/A 093D RW 0 6651980 NR 0571 WD 0 6651980 C.D Suspended
N/A 094D RW 0 6837692 NR 0581 WD 0 6837692 C.D Suspended
N/A 095D RW 0 6849742 NR 0591 WD 0 6849742 C.D Suspended
N/A 096D RW 0 6584350 NR 05A1 WD 0 6584350 C.D Suspended
N/A 097D RW 0 5745442 NR 0688 WD 0 5745442 C.D Suspended
N/A 098D RW 0 6424750 NR 06C1 WD 0 6424750 C.D Suspended
N/A 099D RW 0 6773812 NR 06E1 WD 0 6773812 C.D Suspended
N/A 09AD RW 0 6917290 NR 06F1 WD 0 6917290 C.D Suspended
N/A 09BD RW 0 6660884 NR 070D WD 0 6660884 C.D Suspended
N/A 09CD RW 0 6004616 NR 071D WD 0 6004616 C.D Suspended
N/A 09DD RW 0 6169454 NR 072D WD 0 6169454 C.D Suspended
N/A 09ED RW 0 6690572 NR 073D WD 0 6690572 C.D Suspended
N/A 09FD RW 0 6935506 NR 074D WD 0 6935506 C.D Suspended
N/A 0A0D RW 0 6747480 NR 075D WD 0 6747480 C.D Suspended
Total -------- -------- -------- --------
Track(s) 0 131182408 0 91993570
MB(s) 0 4099450 0 2874799
Legend for MODES:
M(ode of Operation): A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy
D(omino) : X = Enabled, . = Disabled
A(daptive Copy) : D = Disk Mode, W = WP Mode, . = ACp off
(The pairs are Suspended because of an explicit action - the same phenomenon occurred while the pairs were still in SyncInProg.)
I don't quite understand why some devices have "0" in the R2 Invalid Tracks view (as seen from the R2 side), and some other devices have a large number. Even after an explicit "symrdf merge" command, these numbers remain the same: some pairs have 0 R2 Invalid Tracks on the R2 side, other pairs have a large amount of R2 Invalids on the R2 side.
On another pair of DMX'es, the same procedure resulted in a group having *all* pairs with 0 R2 Invalids on the R2 side.
While the synchronisation process runs fine, I'd like to understand the difference between these pairs. If someone here could explain this, I'd be grateful.
Message was edited by: Removed Symmetrix ID numbers.
KCSCP
- New metadevices were formed, consisting of 1 header and 15 members each. The same amount of meta's were formed on the R1 box as on the R2 box.
- The meta's are Dynamic Capable and were added to an empty Dynamic RDF group, using "createpair -invalidate R2 -type R1".
- The pairs were then put in ACP Disk mode using "set mode acp_disk", and a "symrdf establish" command was given.
This all works fine, data was flowing from the R1 to the R2 as you would expect. However, the output of a query shows the following:
Symmetrix ID : 000xxxxxxxxx
Remote Symmetrix ID : 000xxxxxxxxx
RDF (RA) Group Number : 42 (29)
Source (R1) View Target (R2) View MODES
-------------------------------- ------------------------ ----- ------------
ST LI ST
Standard A N A
Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair
Device Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE
-------------------------------- -- ------------------------ ----- ------------
N/A 00EC RW 0 6405130 NR 00EC WD 0 0 C.D Suspended
N/A 00FC RW 0 5891534 NR 00FC WD 0 0 C.D Suspended
N/A 010C RW 0 6623350 NR 010C WD 0 0 C.D Suspended
N/A 011C RW 0 6898842 NR 011C WD 0 0 C.D Suspended
N/A 012C RW 0 6776868 NR 012C WD 0 0 C.D Suspended
N/A 013C RW 0 6593114 NR 013C WD 0 0 C.D Suspended
N/A 093D RW 0 6651980 NR 0571 WD 0 6651980 C.D Suspended
N/A 094D RW 0 6837692 NR 0581 WD 0 6837692 C.D Suspended
N/A 095D RW 0 6849742 NR 0591 WD 0 6849742 C.D Suspended
N/A 096D RW 0 6584350 NR 05A1 WD 0 6584350 C.D Suspended
N/A 097D RW 0 5745442 NR 0688 WD 0 5745442 C.D Suspended
N/A 098D RW 0 6424750 NR 06C1 WD 0 6424750 C.D Suspended
N/A 099D RW 0 6773812 NR 06E1 WD 0 6773812 C.D Suspended
N/A 09AD RW 0 6917290 NR 06F1 WD 0 6917290 C.D Suspended
N/A 09BD RW 0 6660884 NR 070D WD 0 6660884 C.D Suspended
N/A 09CD RW 0 6004616 NR 071D WD 0 6004616 C.D Suspended
N/A 09DD RW 0 6169454 NR 072D WD 0 6169454 C.D Suspended
N/A 09ED RW 0 6690572 NR 073D WD 0 6690572 C.D Suspended
N/A 09FD RW 0 6935506 NR 074D WD 0 6935506 C.D Suspended
N/A 0A0D RW 0 6747480 NR 075D WD 0 6747480 C.D Suspended
Total -------- -------- -------- --------
Track(s) 0 131182408 0 91993570
MB(s) 0 4099450 0 2874799
Legend for MODES:
M(ode of Operation): A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy
D(omino) : X = Enabled, . = Disabled
A(daptive Copy) : D = Disk Mode, W = WP Mode, . = ACp off
(The pairs are Suspended because of an explicit action - the same phenomenon occurred while the pairs were still in SyncInProg.)
I don't quite understand why some devices have "0" in the R2 Invalid Tracks view (as seen from the R2 side), and some other devices have a large number. Even after an explicit "symrdf merge" command, these numbers remain the same: some pairs have 0 R2 Invalid Tracks on the R2 side, other pairs have a large amount of R2 Invalids on the R2 side.
On another pair of DMX'es, the same procedure resulted in a group having *all* pairs with 0 R2 Invalids on the R2 side.
While the synchronisation process runs fine, I'd like to understand the difference between these pairs. If someone here could explain this, I'd be grateful.
Message was edited by: Removed Symmetrix ID numbers.
KCSCP
No Events found!
Jurjen_Oskam
56 Posts
0
July 22nd, 2008 02:00
I have found out what the R2 Invalid Track Count (as seen from the R2 side) means, and what happens when a createpair is done.
When a createpair is done, on both the R1 and R2 one of the four available mirrorpositions will be allocated for SRDF use. Let's say that M1 and M2 are used for local protection, and M3 is allocated for SRDF. When this M3 is allocated, there is an unknown number of invalid tracks in that position, both on the R1 and the R2 side.
On the R1 side, this normally doesn't matter: often you'll perform something like "-invalidate R2" when doing the createpair. Because of the "-invalidate R2", the R1 DMX will explicitly mark all tracks as invalid on the M3 mirror position. In the output of the query command below, this is shown in the "R2 Inv Tracks" counter in the R1 View.
On the R2 side, something needs to be done when the M3 for an R2 device has a non-zero number of invalid tracks. (Remember that the M3 contains an unknown number of invalid tracks at createpair time.) If there are more than zero invalid tracks in the M3 position, the SRDF Merge Track Tables will fail. So, the R2 DMX will zero out the M3 position, and transfer any invalid tracks to the M1/M2-positions. In the output of the query command below, the "R1 Inv Track" counter in the R2 View shows the number of invalid tracks in the M3 mirror position, and the "R2 Inv Track" counter in the R2 View shows the number of invalid tracks which are invalid in both the M1 and M2 mirror position of the R2.
This explains the output of the query command below: for some pairs, the newly allocated mirror position on the R2 device happened to have zero invalid tracks. For other pairs, the new mirror position happened to have many invalid tracks. Any invalid tracks were converted to local invalids, and therefore showed up in the "R2 Inv Tracks" counter on the R2 view.