[email protected] (Phil Smith III) writes: > And I'm 99.9% sure that DASD capacity was determined by building the > geometry and then trying various densities until error rates became > unacceptable, then backing off slightly. Which would explain the > weird, random sizes with each generation (until 3390, after which it > went to arrays and became standardized-on what future generations will > consider a weird size).
error detecting/correcting started moving to fixed block sizes ... aka, FBA ... even 3380 had fixed cell size for error correcting ... however POK's favorite son operating system has had difficulty weening off CKD. There hasn't been real CKD made for decades, all being simulated on industry standard fixed block disks. the recent move from 512byte to 4096byte fixed blocks is largely motivated by error correct. fixed-block https://en.wikipedia.org/wiki/Fixed-block_architecture FBA 512->4096 migration https://en.wikipedia.org/wiki/Advanced_Format original "raid" patent was by IBMer in the 70s https://en.wikipedia.org/wiki/RAID first use was IBM S/38 ... because common single disk failure took out everything. part of S/38 organization simplification was scatter allocation across all disks (treated as single filesystem) ... and therefor any single disk failure took out the whole system ... all disks had to be backed up as single unit/pool (because of scatter allocation) ... and any recovery required complete system restore. Note originally 3380 had 20 track spacings between each data-track ... flying lower met adjacent tracks had less interferance and cut the data track spacing in half (double-density with twice the number of tracks/cylinders), then spacing cut again for triple-density (three times the number of tracks/cylinders). trivia: I got dragged into idea the IBM "father of risc" had for "wide-head" 16 adjacent datatracks with servo tracks on either side ... read/write all 16 simultaneously (while tracking servo tracks on both sides of the data tracks). This was in 3090 and 3380 triple-density time-frame. The problem was that the IBM mainframe data transfer is 16*3mbytes/sec or 48mbytes/sec. Even when ESCON is announced in 1990 (with ES/9000, when ESCON is alread obsolete) it is only 17mbytes/sec. little more trivia: 70s, engineer was running "air bearing" (floating heads) simulation (part of reducing head flying height enabling greater densities) on research 370/195 ... but only getting a couple turn arounds a month (even with priority designation). I had done enhanced bullet proof, never fail operating system for bldg 14&15 allowing them moving from stand-alone testing to doing concurrent development testing under operating system. Turns out even concurrent testing only used percent or two of processor ... so we set up private online service using the machines. Bldg15 had 2ndor3rd engineering 3033 from POK, and we get the air bearing simulation moved over to the 3033, where he can get several turn-arounds a day (even tho 3033 has little less than 1/2 processing of 370/195). more trivia: I had done channel-extender support in 1980 for STL that was moving 300 people from IMS group to offsite bldg ... but the POK people playing with what becomes ESCON ... blocks it release to customer. In 1988, I'm asked to help LLNL standardize some serial stuff they are playing with which quickly becomes fiber-channel standard, including some stuff that I had one in 1980 (FCS, originally 100mbyte/sec concurrent in both directions). Then some POK engineers get involved in FCS and define a protocol that radically cuts the native throughput ... which is eventually released as FICON. Most recent published FICON numbers I've seen is peak I/O z196 test that used 104 FICON (running over 104 FCS) getting 2M IOPS. About the same time there was FCS announced for E5-2600 blade claiming over million IOPS (two such FCS, getting more throughput than 104 FICON running over 104 FCS). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
