In a message dated 1/21/2008 10:39:36 A.M. Central Standard Time, [EMAIL PROTECTED] writes: >It looks like the GDPS group also misunderstood CFW. ... >Excerpt from GDPS >You should eliminate any known exploitation of Cache Fast Write (CFW). Disk write operations using CFW (Cache Fast Write) are written into cache but not to the disk. Having CFW operations in progress at the time a HyperSwap occurs can yield unpredictable results since there is no corresponding mirrored cache content in the secondary disk subsystem. Any known exploiters of CFW (such as DFSORT) should be customized to not use CFW. It looks to me rather that the GDPS group did not misunderstand CFW, since they are saying not to use CFW with GDPS, then they explain why not, and in their explanation they offer what looks like a correct understanding of CFW. GDPS uses PPRC to keep a secondary volume in synch with a primary volume. When data is written to a primary PPRC volume, the primary controller writes the data into its (primary) cache, sends the data down the communications link to the secondary volume's controller which then writes that data into its (the secondary's) cache, sends a signal back to the primary controller that the data is now safely in the secondary's cache, and then and only then will the primary controller signal that the I/O request on the primary LPAR is complete. (The order of the first two operations I described above could be reversed without affecting the final outcome, namely that the primary I/O is not deemed complete until the secondary is known to have a valid copy of the data. But it may well be that the controller does both of these operations simultaneously for performance reasons. I don't know that detail. And in fact the controller should, in my opinion, start writing the data to the comm link before writing it into its cache, since the comm link operation could take a much longer time to complete than the cache operation if the secondary's distance is great enough.) The designers of the PPRC microcode could have chosen to support CFW operations on a primary PPRC I/O request, but evidently decided not to. They documented this somewhere, and the GDPS group were able to find it and write a warning not to use CFW on a PPRC primary. The purpose of CFW data is for easily recreatable, intermediate data that almost never really needs to be made permanent. Sort work files are an excellent example of CFW data. I don't see why anything bad could happen if you allow CFW data onto a PPRC primary, since presumably the CFW is easily recreatable. And you probably would not want to send such data down a communications link anyway. I am here speaking of normal operations. When Hyperswap gets involved, there is an abnormal operation underway. I suspect the warning against CFW on a PPRC primary is self-defensive overkill on the part of the GDPS lawyers. Bill Fairchild Franklin, TN
**************Start the year off right. Easy ways to stay in shape. http://body.aol.com/fitness/winter-exercise?NCID=aolcmp00300000002489 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
