Mark,
A MirrorView relationship cannot be changed "on the fly" from Synchronous to Asynchronous (or from Asynchronous to Synchronous). Changing is done by deleting the existing MirrorView relationship, and creating a new one. Creating a new MirrorView relationship will, by default, fully populate the secondary (perform a a full copy from the primary).

It is possible, provided the primary image is taken offline (that is, there is _no_ host IO going to it) to skip the initial synchronization (there's an option via Navisphere to tell the array that the secondary image is already sync'd with the primary image). This possibility should be used with much care, since if the primary image is not truly completely offline while the relationship is being deleted and re-created, discrepancies between the images could occur.

Regards,
DGM

Even without I/O concerns, there will likely be a slight increase in latency when using 10K's as your target, simply because the drive's response time will be longer.

In addition to the other caveats mentioned, MirrorviewA requires SNAP cache (a.k.a. reserve LUN pool) and a separate license.

Message was edited by:
SANDoozer

Message was edited by:
SANDoozer

Are you saying that the Ack is sent when the target data is written to disk, not write cache, on the target CX?

I read page 9, but it didn't seem to discern between disk and write cache.

If so, has it always been this way?

Thanks

Sorry, I was just trying to edit my comment, but the forum wouldn't allow me -

I should have said that once the write on the secondary is written into write cache, it does not have to wait until actually written to disk (unless write cache is disabled for some reason).

glen

I should have added some additional details.

I believe the acknowlegement on a write is sent as soon as the I/O hits the write cache of the target CX. This means that unless you're over cache is nearly full, the 10K speed of the target drives will usually have no effect on latency.

Also, unless something has changed since release 16, MirrorviewA would likely add significantly more latency than Mirrorview would using 10K target drives. The instant you start replicating with MirrorviewA, you're actually creating a snapshot of the source LUN. This means that the CX does not send and Ack for a write when the I/O hits write cache. The Ack happens after the orignial data is written to the SNAP cache and, I believe, the new data is written to disk. Then the Ack is sent. This was true with rel 16, but could have been changed since.

null

For Mirrorview/S the write is not acknowledged until the secondary is written - see page 9 in the Mirrorview Knowledgebook

White Paper: MirrorView Knowledgebook: FLARE 28 - A Detailed Review

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/H2417_clariion_mirrorview_asynch_dr_wp_ldv.pdf

glen