On 2/20/07, Tom Duerbusch <[EMAIL PROTECTED]> wrote:
In what cases is this a problem? I want to know, in what circumstances I'm going down a path, that is different than I think.
I fear I don't know the details anymore of that particular event. All I remember is that fixes were required to make Linux use mini disks allocated on a later or different model of the ESS. But if you look at a snippet of source code like here for example http://lxr.linux.no/source/drivers/s390/block/dasd_eckd.c?v=2.6.18;a=s390#L67 you can see the information is there and there obviously was a reason to differentiate. And I certainly know about one case where disk I/O performance was worse on new DASD because of such differentiation. Would you believe that still in this century our friends in Boeblingen implemented RPS in the disk driver? Linux is not unique in this. I still remember that the SE of our non-IBM DASD implemented (unplanned) a performance fix for the microcode. All it did (as we learned after brown stuff some air movement devices) was to set a bit in some status field returned to the OS. And z/OS used that to identify features of 3990 control units. While the concept did not apply to this RAID device, it fooled z/OS enough to exploit some of the features. Unfortunately, VM passed that status field also to VSE guests that then failed to recognize the control unit and gave up.
For example, right now, our zLinux disaster recovery option is to find a replacement processor (perhaps the next processor off of IBM's line),
Would you also be willing to take the load of a z990 to someone's z9 for disaster recovery? Back then when I was involved in such things I do remember we applied preventive maintenance on VM for future models because of such arrangements. But VM does not isolate the guest from those details (as folks using ISV products with CPUID based license code know). We just have been spoiled by CMS behaving so well that we take this all for granted. I often disagree with Alan (also) about this. Probably because I sometimes do get out ;-) I believe VM should reveal far less details about the actual resources so we don't challenge developers to take advantage of the details that shine through our virtualization. I believe there's often no value for a class G user to know what real device or real volser his mini disk is - it's a disk and it's so big, and that's what you need to know. Let alone a Q MDISK that reveals the actual owner for indirect links. Yes, we had a smart developer who found which disk $FORTRAN 200 really was and improved his performance by linking that directly. So after I upgraded he still used the old version and reported problems that I was sure to have fixed... If we did not have VSWITCH, most certainly the OSA devices would have caused a nightmare too. The problems we have seen there are mostly because they chose to simulate existing hardware to avoid writing one extra clean and elegant driver in Linux. It all comes down to abstraction and architecture. VM needs to provide an abstraction of the true resources in such a way that the virtual machine can make clear what function is needed, and CP can then deliver that in the "best" way (weighing technical and economical aspects). The challenge is to have an abstraction that is powerful and flexible enough, and yet efficient to implement and compatible till we retire. Normally that means a high-level interface. To have both VM and the guest imitate a low-level interface of a device that was extinct already 25 years ago, that's a burden to both... To define such abstractions is hard work, but I strongly believe it is more effective than trying to imitate the latest hardware. If it were my choice, Linux on z/VM would just be using (an improved version of) the diagnose I/O interface rather than doing channel programs. Yes, I will shut up now. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
