Anne & Lynn Wheeler <l...@garlic.com> writes: > data-transfer channel program. Cache operation was also write > "store-through" ... aka synchronous to disk ... and no indication that > 3880 controller would do its own seek operation (to move to different > track for pre-fetch) independent of what was explicit from some channel > program.
re: http://www.garlic.com/~lynn/2012d.html#72 megabytes per second http://www.garlic.com/~lynn/2012d.html#75 megabytes per second also http://www.garlic.com/~lynn/2012d.html#73 Execution Velocity http://www.garlic.com/~lynn/2012d.html#74 Execution Velocity at least by 80s, some processors were started to do "store-into" caches (rather than store-through) for additional performance ... store operation happened in cache and write could be done asynchronously at some later point without involving stalling instructions (with store operations). Issue with disk caches (& "store-into" for later writting as opposed to "store-through") was processor cache&memory data was typically viewed as ephemeral ... i.e. in power failure, changes weren't expected to survive. However, for disk caches ... store-into had to wait until there was (typically redundant) battery-backed &/or flash memory ... since data written to "disk" was expected to survive power failure (would survive in cache until power was sufficient to eventually write to disk). note that ibm dasd/channel operation use to have peculiar power-failure, failure mode for a long time. data to be written was in processor memory and if power failed in the middle of the write operation ... there could be sufficient power for the disk to complete the write operation ... but not enough to power processor memory and transfer of data to disk. The symptoms was that disk would propagate write with all zeros ... and then write correct error code for the partial zero record (no hardware error condition). there were even countermeasure system designs through the 80s that all physical records were guarenteed to end in non-zero (systeme) data ... what wouldn't be seen by applications ... as a validity check for power-failure partially valid record with propagated zeros. FBA drives developed strategy that there was sufficient power and data to always complete a write operation, once it started. Once all CKD DASD migrated to simulation on top of FBA (there hasn't been any real CKD DASD for decades) ... along with various intermediate cache memory ... there problem has been mitigated. misc. past posts mentioning CKD & FBA http://www.garlic.com/~lynn/submain.html#dasd misc. past posts mentioning getting to play disk engineer in bldgs. 14&15 http://www.garlic.com/~lynn/subtopic.html#disk -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
