I said (to John): > > > S/390 does also have FBA (fixed block architecture) DASD devices. > > > Sadly, even in the Linux world these are not widely known or used. > > > I maintain that they should be employed heavily and heartily! > > > The benefits are numerous.
On Thu, 18 Apr 2002, Jay Maynard wrote: > Oh? Like what? Using FBA hardware alleviates the need for the DASD driver to deal with C/H/S translation and work directly with blocks. A UNIX filesystem is a structure placed into a string-of-bytes. Where the hardware looks like a string-of-bytes, it is (theoretically, and I say in practice too) easier for the system to present a linear space since the device is already linear. Why does loop-back mounting work? Why is LBA preferred on PC hardware nowadays? Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. The support system may (in my case does) complain about no IBM volser, but it works as expected. I installed SuSE 7.0 directly from CD, as far as the S/390 knew. (It was an ISO image, but the S/390 did not know that it was not a CD copied block-for-block onto a 3370.) So CD could be attached to zSeries neatly if attached as FBA. With FBA, the effect of DDR approaches the effect of the Linux (UNIX) command 'dd' for copying a volume. And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. > Remember that, these days, most DASD is made up of huge RAID > arrays emulating either classic FBA or CKD devices, and the emulation > overhead of either is pretty small. Right. And since the actual backing store is fixed-block, I say let that which is presented also be fixed-block and ditch the track, record, count, and key info and the associated work. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? John said: > > Back when I was a sysprog we used VS1, and that had no support for FBA > > devices (I think the 3370 was supported on MVS back then). then Jay said: > MVS never has supported any FBA devices. The problem is that the CKD > architecture is heavily embedded deep in two critical pieces of the MVS > core: program fetch and VTOC processing. I'm not familiar with the details > of PDSEs for program fetch, but if load libraries are PDSes, they're still > searched by SEARCH KEY CCWs. But VSE and VM both work with FBA DASD. I'm not saying that we should endorse FBA to the demise of MVS. I am only saying that we should endorse FBA to the benefit of Linux, VM, and VSE. And with modern DASD subsystems, it should be no great pain to present either flavor as needed. Let MVS have its CKD. But let the rest have FBA when they want.
