[email protected] (Tom Brennan) writes: > This reminds me of my first (junk pile) floppy disk drive back in the > 1970's for my home-made computer. I had little money so I made my own > controller out of a dozen chips and wrote some 8080 code to handle the > I/O. So the format of the disk was totally up to me, and not > compatible with anything else. I did just what you said and settled > on about 3K per track. But that was with no separate records or > sectors - you had to read the entire track if you wanted any data, > which I found out later (when I took my first computer class) wasn't > too smart.
re: http://www.garlic.com/~lynn/2019b.html#52 S/360 http://www.garlic.com/~lynn/2019b.html#53 S/360 recent (facebook ibm retirees) post ... with 3390/3990, iceberg, seastar, etc: IBM Adstar tried to counter (STK Iceberg) with seastar (software was seahorse) ... current web search for references just turn up my old usenet posts I've archived at garlic.com ... which have old online references that have gone 404 ... although some of them still live at the wayback machine https://web.archive.org/web/20080608164743/http://www.informationweek.com/565/65mtrob.htm https://web.archive.org/web/20060328034324/http://www.stkhi.com/nearline.htm Besides working with LLNL on technical cluster scaleup "supercomputers" ... we were also working with LLNL on porting their high-performance filesystem LINCS they had originally done on Cray ... including HA/CMP version (Unitree). As I've periodically mentioned before ... a week or two later we had meeting in ellison's conference on commercial cluster scaleup, reference http://www.garlic.com/~lynn/95.html#13 then a couple weeks after that meeting, cluster scaleup was transferred, announced as IBM supercomputer (for technical/scientifc "ONLY") and we were told we couldn't work on anything with more than four processors (we leave IBM a few months later) Date: Mon, 30 Dec 91 15:07:32 -0800 To: wheeler Subject: Unitree log structured filesystem Lynn, this could be useful for the high-end for a non-obvious reason. We recently removed the only future CKD 5.25" DASD from the plan. The next high-end DASD, Cortez, will do CKD emulation. Emulation is the right way to do CKD, but unfortunately Cortez is forced to emulate behind a 3990. This is badness because the DDC interface behind a 3990 is gap-synchronous. This means there is a Read-Modify-Write cycle to do a write. This is inherent to a 3990. The only way to do CKD Emulation correctly is to get rid of 3990. Seastar plans to do this, but not until 2Q95. In the interim, we need a high performance high-end CKD subsystem. We would like array support if possible, and compression. What has this to do with HA/Unitree LFS you ask? If we added some ESCON cards to an HA/950, and we did CKD Emulation SW and Compression HW here at ARC, we could quickly build a cached/arrayed/CKD subystem. We could stripe data across Harrier drawers 3+P. We could compress because we have LSFS (update in place precludes compression). We could cache in Unitree memory. Would this work ? It would be really keen. ... snip ... In late 70s and first part of 80s, I got to spend some time playing disk engineer in bldgs 14&15 ... but later 80s, I was spending more time on risc & turning out HA/CMP product. Above email references HA/950 ... which is HA/CMP running on RS6000/950 (product started out HA/6000, but I fairly quickly renamed HA/CMP when started on cluster scaleup) ... high-end rack mounted system. I've previous mentioned that ESCON was announced in 1990 with ES/9000 when it was already obsolete. In 1988, I was (also) asked to help LLNL standardize some serial stuff that they had been playing with which quickly becomes fibre channel standard (including some stuff that I had done in 1980), initially 100mbyte/sec concurrent in both direction, compared to ESCON 17mbyte/sec half-duplex. The post about Jan1992 Ellison commercial cluster scaleup (128-way ye1992) meeting, and the above email mentions Harrier(/9333) which we were using in some HA/CMP configurations. It was high-speed fixed-block disks using packetized SCSI protocol running over 80mbit/sec full-duplex serial copper. I mention that I had hoped that it evolves into 1/8th speed interoperable fibre-channel standard ... but instead it evolves into IBM proprietary SSA (after we leave): https://en.wikipedia.org/wiki/Serial_Storage_Architecture The above wiki mentions that SSA was "overtaken" by FCS, but I had been asked to help with standardizing what becomes FCS in 1988 ... and I wanted Harrier/9333 to evolve into FCS interoperable instead of IBM proprietary ... end of ibm retiree post ... aka, real CKD DASD hasn't been made for decades ... but POK's favorite son operating system has not been able to ween itself off it. as mentioned previously, somewhere along the way, some POK engineers become involved with FCS and define an extremely heavyweight protocol that drastically reduces the native throughput, eventually released as FICON. Latest published "peak i/o" benchmark I've seen is for z196 getting 2M IOPS using 104 FICON running over 104 FCS. About the same time a FCS was announced for E5-2600 blade claiming over million IOPS (two such FCS getting higher throughput than 104 FICON running over 104 FCS). past posts mentioning FICON http://www.garlic.com/~lynn/submisc.html#ficon HA/CMP posts http://www.garlic.com/~lynn/subtopic.html#hacmp some old archived cluster scaleup posts http://www.garlic.com/~lynn/lhwemail.html#medusa -- 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
