Discussion:
Cache Fast Write (CFW) - Data in the CFW is *not* mirrored, is it?
Add Reply
Peter Hunkeler
2015-06-01 13:49:29 UTC
Reply
Permalink
Raw Message
My GDPS mate asked us to make sure that cache fast write (CFW) on out (PPRC) mirrored boxes is disabled because it is not compatible with HyperSwap. This statement presumes that data in the CFW is not mirrored, is it?



Up to now, I got somewhat inconsistent informtion about CFW in current DASD subsystems. Trying to get a clear view with the help of specialist here on the list.


I understand that CFW can be switched on/off via IDCAMS. While this can be protected via RACF, this is not bullet proof. Some software (DFSort?) might write its own channel programm to set the switch.


I therefore asked our DASD provider if CFW can be permanently disabled on the box. Got a "Yes, but nobody does it"....


Talking to someone else, I was told that modern DASD subsystems always use CFW; the user has no influence in this (??)


Finally I haven't been able to figure out whether data in the CFW cache is mirrored *before* of *after* the data has been hardened to the platter.


Appreciate any insight. Thanks in advance




--
Peter Hunkeler

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Shane Ginnane
2015-06-01 13:55:32 UTC
Reply
Permalink
Raw Message
Where's Ron when we need him ?.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2015-06-02 15:51:29 UTC
Reply
Permalink
Raw Message
Post by Shane Ginnane
Where's Ron when we need him ?.
Yep, but what does this help me?


--
Peter Hunkeler





----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
p***@gmail.com
2018-01-12 11:02:38 UTC
Reply
Permalink
Raw Message
Almost certainly too late for the original poster, but for the benefit of anyone else searching for an answer...
From the TPCR for System z Red Book:

Cache Fast Write (CFW) is a disk subsystem feature that allows the exploiters of this function to write temporary data to disk subsystem cache, but not to disk. DFSORT exploits this function. If Cache Fast Write is enabled on a PPRC primary, it is executed as a DASD Fast Write (DFW).
When an I/O is received that specifies CFW, it comes with a CFWID. This CFWID is compared to the one stored by the storage controller. If it does not match, the storage controller rejects the I/O and the sort job fails. This mechanism is designed to ensure that if the cache contents are lost, the job knows it. So if one of the CECs in the storage system fails, and you failover to the other, the sort jobs will fail because the cache contents has been lost.
Similarly, if there is a HyperSwap to a different storage system, the CFWID will not match and the job will fail. In that case, there has not been any loss of data, but the job still fails. This is why CFW should be disabled.
When PPRC is active, even if CFW is not disabled, the storage system will not honor it; rather, it will convert CFW to DFW in the storage system. So disabling at the host does not change performance at all, it merely allows the sort job to survive the HyperSwap.
Applications that exploit Cache Fast Write include DFSORT and SyncSort.
Loading...