SRDF copy

I assume your specific question is around performing an SRDF COPY as opposed to on-going replication of devices that are already in synch?

For adaptive copy disk mode (the recommended mode for copy operations) the copy is track based. SRDF figures out which tracks are owed and sends them in the copy process. There is a level of efficiency if the array knows that the data is completely zeroed on both sides. In this case, the copy of zero data does not actually take place, but the tracks are marked as in synch. For example on a new array pair, if the SRDF setup takes place before host access, all tracks will be considered as never previously been updated and SRDF will not actually copy the zero data. If there has been some host update, only the tracks updated by the host will be copied, the rest will be marked in synch without having been copied.

Thank you Jasonc for answering.

Actually we had set up SRDF Sync copy for boot LUN and MBR records didnt get copied to R2 disk. Linux team had to do it manually.

So I just wanted to check if SRDF copies bit by bit and all empty spaces of just the written tracks.

Also when I see written tracks on R1 and R2 TDEVs, they are slightly different in numbers.

R1 disk:

++++++

Enabled Capacity (Tracks) : 18211234068

Bound   Capacity (Tracks) :     552420

                 S Y M M E T R I X   T H I N   D E V I C E S

------------------------------------------------------------------------------

                                         Total          Total       Compressed

       Bound      Flgs      Total      Allocated       Written      Size/Ratio

Sym  Pool Name    EMPT     Tracks     Tracks (%)     Tracks (%)     Tracks (%)

---- ------------ ---- ---------- ---------- --- ---------- --- ---------- ---

8179 T16R62TB72S  F..B     552420     209856  38     208669  38     209856   0

R2 disk:

++++++

Enabled Capacity (Tracks) : 8751784068

Bound   Capacity (Tracks) :     552420

                 S Y M M E T R I X   T H I N   D E V I C E S

------------------------------------------------------------------------------

                                         Total          Total       Compressed

       Bound      Flgs      Total      Allocated       Written      Size/Ratio

Sym  Pool Name    EMPT     Tracks     Tracks (%)     Tracks (%)     Tracks (%)

---- ------------ ---- ---------- ---------- --- ---------- --- ---------- ---

66EA T16R62TB72S  F..B     552420     209856  38     208033  38     209856   0

Thanks In Advance!

Yes, we shut down the R1 and R2 host before Split and mounted it to R2 host. There were 0 invalid tracks on both sides when we had split the SRDF. Its a Linux physical server.

When we split the SRDF:

       Target (R2) View                 Source (R1) 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 MDAE  STATE

-------------------------------- -- ------------------------ ----- ------------

DEV001  6887 RW       0        0 NR 817A RW       0        0 S...  Split

DEV002  66EA RW       0        0 NR 8179 RW       0        0 S...  Split

And current situation:

       Target (R2) View                 Source (R1) 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 MDAE  STATE

-------------------------------- -- ------------------------ ----- ------------

DEV001  6887 WD       0        0 RW 817A RW       0        0 S...  Synchronized

DEV002  66EA WD       0        0 RW 8179 RW       0        0 S...  Synchronized

Total          -------- --------           -------- --------

When the R1 and R2 devices are in synch (zero invalid tracks on each side) the R2 is a block-by-block mirror image of what is on the R1 device.

Did the OS get shutdown or file systems unmounted on the R1 side before the the RDF devices were split and mounted on R2 host?  i.e. were all of the disk writes from the OS perspective actually hardened to disk before the R2 was split?

Is this a physical or virtual environment?

I'm not quite sure what to make of the difference in written tracks yet.Would you mind posting symrdf output please?

This output was taken before remediation. After remediation the output looked like:

       Target (R2) View                 Source (R1) 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 MDAE  STATE

-------------------------------- -- ------------------------ ----- ------------

DEV001  6887 RW       3        0 NR 817A RW       0        0 S...  Split

DEV002  66EA RW    1652        0 NR 8179 RW       0        0 S...  Split

I have never seen anyone before complaining about this earlier. We had been performed lot of DR exercises (quarterly atleast one). This is the first time LINUX team has brought this up.

Just last question: So SRDF wont copy empty spaces in R1 disk to R2 disk?

Thanks Aimw, good job keeping the output.

At what point in the process is the query showing the SPLIT state? Before or after the R2 host lun remediation? If it is before then the output makes sense. If it is after, then there there should have been invalid tracks built up on the R2.

SRDF is not aware of any disk structures such as MBR, private regions or such. As far as SRDF is concerned it's all about the block device. So I am going to take the point of view at this stage that it's likely that the functional integrity of SRDF mirroring is in tact and ask:

-    Is the issue Repeatable?

-    If this test has been carried out successfully on other hosts (same and or different platform)?

-     Was a (tested and proven) run book used to execute the procedure?

As an FYI there is an SRDF background process called Remote Data Compere (RDC) its job is to validate that the R1 and R2 devices are indeed a mirror of each other. If there is a general issue in your environment where the RDF devices don't match up EMC would be notified via RDC posting an exception.

Thank you Jasonc!