1 Nickel

SRDFA write-pending limit reached


     We received a message...RDFA_SESS_DROP_WPL_ENBL...documentation states that this

     "SRDF/A Session dropped, write pending limit reached. Host throttling enabled Error"

     Does this mean that the network link between the R1 and R2 frames has slowed down for some reason, or network link dropped, although the client states there were now network issues, or the R2 frame slowed down and could not keep up?

SYMEVENT did find this..

Sat Jan 18 03:20:58 2014 RE-9G  Symm RDF    (02) Error        0x004a
SRDF/A Session dropped, write pending limit reached.Host throttling disabled

     The odd part is the director RE-9G is offline and is not used we are using H directors which symevent has not identifed any of those showing with any issue.

Labels (1)
0 Kudos
4 Replies
4 Germanium

Re: SRDFA write-pending limit reached

Another possibility is that the host workload increased.

1 Nickel

Re: SRDFA write-pending limit reached

That is a possibility, but knowing that the R1 devices during heavy processing/IO we have not reached this limit during those times, or when the client makes several changes to the data on the R1 side that this does not happen. When this was received there was not much processing going on at the time the write-pending limit was reached. It was not identified until several hours later that one of the RDF GROUP links was suspended.

0 Kudos
4 Ruthenium

Re: SRDFA write-pending limit reached

Have you seen the WP track going down after the director is back online and link recovered? You'd better to switch the SRDF to adaptive copy mode which will move slot faster. See the KB for the steps:

0 Kudos
2 Iron

Re: SRDFA write-pending limit reached

Verify that the number of invalid tracks is below 30,000
It could be a dangerous situation if SRDF/A mode is activated with a large number of invalid tracks. It is a best practice to switch into SRDF/A mode once the total amount of invalid tracks has fallen below 30,000. Activating SRDF/A with a large number of invalid tracks owed to the R2 side could overload the DA, flood the RDF link, and flood the R1 cache. All of these scenarios could cause the SRDF/A session to drop again. At a minimum, it will have a negative effect on cycle time and could cause other active SRDF/A sessions in the Symmetrix array to experience elongated cycle times.
Before switching into SRDF/A mode, you should remain in adaptive copy disk mode until the invalid track count falls below 30,000, or one cycle set of data. This way you greatly minimize your risk of flooding the cache or your link.
Using the example shown below, enter the symrdf query command for your device group to determine the invalid track count.
symrdf -g pocsun100data query -i 5
Device Group (DG) Name             : pocsun100data
DG's Type                          : RDF1
DG's Symmetrix ID                  : 000187461502

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

DEV001  00E1 RW       0  25891   RW 00E1 WD   0     0   C.D  SyncInProg
DEV002  00E2 RW       0      0   RW 00E2 WD   0     0   C.D  Synchronized
DEV003  00E3 RW       0      0   RW 00E3 WD   0     0   C.D  Synchronized
DEV004  00E4 RW       0      0   RW 00E4 WD   0     0   C.D  Synchronized

Total          -------- --------           -------- --------
  Track(s)            0    25891                  0        0
  MB(s)             0.0    809.1                0.0      0.0

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 R2 invalid track columns in this example show that the amount of invalid tracks has fallen below 30,000. Device group pocsun100data has 25,891 invalid tracks. This means that it takes just one SRDF/A cycle switch to make the RDF pairs consistent for both device groups

0 Kudos