>> Well, there seems to be some disagreement here. > And some misunderstanding as well. When Jim talks about multiple paths > for the I/O, it is multiple paths to the control unit (that has a > bunch of devices). So you can have multiple I/O's active at the same > time to different devices on the same control unit. The operating > system can get this without knowing much about it.
Right, I was answering a different question (what I thought was asked). > The other issue is whether you can have multiple I/O's at the same > time to the *same* device (when the read could be satisfied from CU > cache while you wait on the write to complete). Provided the channel > program clearly indicates its intentions you could, but I understand > you need PAV. VM itself does not support PAV, but I think you can > allow the guest to do so on dedicated DASD devices, right? The lack of Parallel Access Volumes (PAV) in z/VM is a problem Barton Robinson has pointed out here before. PAV allows multiple concurrent I/Os to the same volume. With large volumes and a high I/O rate, the lack of PAV support would be a performance issue. By using LVM to stripe a large logical volume across several smaller "physical" volumes (devices) you would get the best of both worlds as you will benefit from the ability of the I/O subsystem and z/VM do perform I/O against concurrent devices on the same control unit. Of course, since the real disk subsystem (say in IBM Shark/ESS or a StorageTek SVA) is already a RAID 5 device with striping, I don't know if the end result of LVM striping and multiple logical paths would give much benefit (as someone pointed out earlier today). I hope I got this right now. Regards, Jim
