Originally posted by: digam

We do have 2 units of IBM DS4700 Storage Server in different sites connected via a SAN Switch and DARK FIBER.
Mirror mode is Synchronous
Site A is primary site and Site B is secondary (mirror) site

Problem:

Case1
a. Created abc.txt file with few lines data.
b. After creating abc.txt, suspended the mirror between Site A and Site B
c. Break the mirror between Site A and Site B
d. Mapped the Storage mirror lun with Site B Server
e. Found abc.txt file in site B without context which is written inside the abc.txt file

Case2

a. Created abc.txt file with few lines data.
b. Waited for few mins (10-15 mins)
b. After creating abc.txt, suspended the mirror between Site A and Site B
c. Break the mirror between Site A and Site B
d. Mapped the Storage mirror lun with Site B Server
e. Found abc.txt file in site B with context which is written inside the abc.txt file

What may be the problem??????

As per IBM Document, in storage level mirror if i save any file in Site A, immediately it will replicate in Site B.

But in my scenario, it is taking time to replicate storage server data.

Please help

Originally posted by: The_Doctor

I've tested Metro Mirroring in SYNC Mode on a DS4800, without problems, so I suspect it should work on a DS4700 ok. But never say never......

in Case 1....

i. did you specifically CLOSE the file "abc.txt" before breaking the mirror between sites ?
ii. your Storage Manager Client will show you the status of the mirror before you break it. Was the STATUS of the remote mirror pair -> SYNCHRONIZED <- before you broke the mirror ?
iii. in step d ..... where you say you mapped the NEW LUN to Server B..... did the "importvg" command indicate any problems ?

If none of this helps, then it sounds like you're running Global Copy or Global Mirroring which is ASYNC. If not, I'd suggest your next call is to IBM Support.

Originally posted by: digam

1. Yes, I closed the abc.txt file before suspend and break the mirror.
2. My Storage Manager Client shows synchronized in mirror status before I suspend and break the mirror.
3. Yes, in secondary site I did importvg
4. MIRROR what I did is METRO MIRROR ie. Synchronized mode

If I wait for few mins (10-15) then do a same process then I can see the context of abc.txt file.

Originally posted by: tony.evans

Firstly, keep in mind, I've no experience of the hardware you're using.

Isn't this just AIX's write-behind file caching in action? The file updates were made in memory but not committed to disk.

Originally posted by: The_Doctor

Beats me what's wrong then.

Is it file caching going on ? Maybe, but I would of thought the specific "CLOSE" of the file would have flushed it to disk. The "CLOSE" should not complete until the data was fully written to BOTH sites.

One idea that migh prove / disprove this is to:

a) write a bunch of new data to the file
b) close the file
c) UNMOUNT the filesytem where the ABC.TXT file resides
d) verify the STATUS is still SYNCHRONIZED
d) break the mirror (no need to suspend the mirror, since you are simulating a disaster as if SITE A is destroyed)
e) importvg the VG on SITE B
f) verify the contents of the file at SITE B

If this doesn't reveal anything new, then:
1. something else is going on that I don't understand, and
2. time to call IBM Support (might be time to call them anyway -:))

Originally posted by: tony.evans

Is closing the file something specific to the mirroring system in use? Because I'm pretty sure AIX doesn't care what state the file itself is in, in terms of the write-behind caching.

Try putting a sync in,

1. create file, add content, exit editor
2. $> sync
3. break mirror
etc.

Originally posted by: tony.evans

Is closing the file something specific to the mirroring system in use? Because I'm pretty sure AIX doesn't care what state the file itself is in, in terms of the write-behind caching.

Try putting a sync in,

1. create file, add content, exit editor
2. $> sync
3. break mirror
etc.

Originally posted by: The_Doctor

yes, I believe you're right. The "CLOSE" itself won't necessarily cause things to get flushed to disk. Worst case, syncd, should kick in (in 60 seconds or less) and cause the data to be flushed to disk.

My brain was focused on the 10-15 minute delay...... and why such a "LONG" delay. I'm bad.

If the original poster runs the "sync" command as you suggested (or waits 60 seconds for "syncd" to kick in) the data should physically be on disk at BOTH sites.