Invalid tracks in the output of "symrdf -g groupname query"

Does this answer your questions:

Synchronizing changed tracks

Synchronizing SRDF devices is based on tracking and managing the changed tracks
on a device with singular commands. The concept of invalid tracks in SRDF systems
indicates what data is not synchronized between the two devices that form an SRDF
pair. On both the source and target sides of an SRDF setup, the Symmetrix array
keeps an account of the tracks that are "owed" to the other side. The owed tracks are
known as remote invalids.

For example, consider the case of an R1 device whose logical connection to its R2 has
been suspended. If both devices are made write-accessible, hosts on both sides of the
RDF link can write to their respective devices, creating R2 invalids on the R1 side and
R1 invalids on the R2 side. Each invalid track represents a track of data that has
changed since the two sides were split. To re-establish the logical link between the R1
and R2, the invalid tracks have to be resolved.

The resolution of invalid tracks depends on which operation you perform. For
instance, you can have remote invalids on both sides prior to an establish or a
restore operation. If so, performing an establish operation indicates to SRDF that
you want to copy modified R1 tracks to the R2 side. In the process, any tracks that
were modified on the R2 side are overwritten with data from corresponding tracks on
the R1 side.

Performing a restore operation indicates the opposite¿that you want to copy
modified R2 tracks to the R1 side. In the process, any tracks that were modified on the
R1 side are overwritten with data from corresponding tracks on the R2 side.

Page 55 of EMC Solutions Enabler Symmetrix SRDF Family CLI Product Guide 6.3

Hi,
For example, consider the case of an R1 device whose logical connection to its R2 has
been suspended. If both devices are made write-accessible, hosts on both sides of the
RDF link can write to their respective devices, creating R2 invalids on the R1 side and
R1 invalids on the R2 side.

As the above you have said the situations that R1 has R2 invalids and R2 has R1 invalids. What about R1 has R1 invalids or R2 has R2 invalids?

I haven't heard of that situation or can think of a sitation which could cause it.

However I have heard of local invalids on an srdf device. e.g. a mirrored srdf device is resyncing a raid 1 mirror due to a drive failure. This tends to confuse people about where the invalids are exactly and I think it upsets some symrdf commands when in this situation.

other posts have nicely described the R1 side R2 invalids and the R2 side R1 invalids.

When you see the other case, is after you perform the "symrdf establish" or "symrdf restore". If you watch the cli command output you will see a step where it says something like "Marking device to refresh from R1" (or something like that). This step sort of moves the invalids from one column to the other.

For example. Lets assume you did perform the RDF split and wrote to the R2 device. As described earlier, your query will show R1 invalids on the R2 side representing the tracks you wrote to on the R2.

Now when you run an establish (telling us to overwrite the r2 updated tracks from the R1 side), that "refresh" step has to move R2 side tracks to the R2 invalid so we know to overlay them from the R1 side.