l...@garlic.com (Anne & Lynn Wheeler) writes: > it never made it as part of release product ... in part because of the > bad rep that single-level-store got from the FS effort ... even though > I could show 3times the throughput/efficiency compared to standard CMS > filesystem (both CDF & EDF) for moderate filesystem workload. some > past posts > http://www.garlic.com/~lynn/submain.html#mmap
re: http://www.garlic.com/~lynn/2013h.html#44 Why does IBM keep saying things like this http://www.garlic.com/~lynn/2013h.html#45 Storage paradigm [was: RE: Data volumes] note that there was two parts of the significant throughput increase going to paged-mapped filesystem ... one is that it is higher level abstraction that allows significant amount of optimization on service the request to be done under the covers. the other is there is a real paradigm mismatch between channel program paradigm and virtual memory ... requiring significant pathlengths to stitch together the mismatch paradigm match/mismatch continues on down ... there is almost direct paradigm match with page mapped filesystem at the top, down through virtual memory operation to fixed-block architecture disk structure; and when there is mismatch requires a lot of extra resources and overhead ... like effort to map CKD to FBA (aka there hasn't been any real CKD disks manufactured for decades). Virtual machines has to scan each channel program, making a copy and replacing virtual addresses for real. CMS standard filesystem used CCWs for i/o ... it was originally developed on the same 360/40 (running stand-alone) as was being used to do CP40 (with added virtual memory hardware). CMS continued to be able to run on "bare machine" all during cp67 ... but there was an artificial cripple put in in the morph from vm370/cms. In the transition from MVT to OS/VS2 (aka virtual memory), the same problem showed up. The original implementation involved putting a little bit of code to create 16mbyte virtual address space for MVT, but the major effort was hacking CCWTRANS (from CP67) into the side of EXCP processing (EXCP had the same problem with access methods creating channel programs in the application virtual address space ... as CP67 did with virtual machine channel programs). Old reference by somebody in POK that was in the middle of the transition to OS/VS2 and virtual memory ... includes reference that OS/VS2 release 2 (MVS) was on glide path to OS/VS2 release 3 (FS) http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory above also mentions that one of the people responsible for HASP having a group doing a TSS-style implementation of OS/360 (that had something like a page-mapped filesystem) One of the big differences (cp67/cms and os/vs2) was that the rest of CP67 I/O processing was as little as 5% of the corresponding OS/VS2 pathlength ... so the additional pathlength for doing channel program duplication with real addresses was less noticeable in OS/VS2 (both SVS and MVS). In fact, one of the big motivations for the SSCH and other changes to I/O for 370-xa was to get some portion of the enormous I/O pathlength moved out of MVS so it could be rewritten (as well as being moved to separate dedicated processors). Starting in the late 70s, I got to play disk engineer in the disk engineering labs and rewrite the I/O supervisor to be bullet proof and never fail ... so they could do concurrent on-demand development testing in operating system environment (they had tried MVS, but found MVS had 15min MTBF in that environment with just a single testcell ... requiring manual re-ipl). However, I also attempted to do further pathlenth reducution (while still supporting never fail) to demonstrate 370 I/O coming as close as possible to 370-xa with separate dedicated processor. past posts mentioning getting to play disk engineer http://www.garlic.com/~lynn/subtopic.html#disk for other topic drift ... FE had 3380 i/o error injection regression tests and even after 3380 was introduced, MVS was failing (requiring re-ipl) for all tests ... and in 2/3rds of the tests, there was no indication what had precipitated the failure. old email: http://www.garlic.com/~lynn/2007.html#email801015 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
