> I always thought, and I may be wrong, that one of the main > advantages to having either a PAV or individual minidisks was > so that instead of having 1 queue for the device, you now > have many.
That's kind of the idea here -- you get sort of a poor-man's PAV via CP getting its hands on the I/O requests and being able to optimize them before you go out the physical disk. If CP can satisfy a request from the minidisk cache, then you avoid the trip to the device at all (which you couldn't do with dedicated devices; Linux would have to figure that out). Increasing the number of minidisk "devices" underneath a LVM takes advantage of this capability. It's especially effective if you have large MDC cache, since CP is more likely to find the block it wants in cache rather than having to go out to disk. > If your first I/O in the queue needs to do a > physical I/O, then all the other I/Os wait. Exactly the situation I'm avoiding here, and keep in mind that what the virtual system (ie, Linux) sees, does NOT have to match the physical system. Let's say we have 11 volumes worth of space. If we have 11 full pack minidisks (or dedicated devices), we can have a maximum of 11 I/O operatiosn in flight at any given time. If I take those 11 volumes and split them up into 3 1000 cylinder chunks each, I can present those 11 volumes as 33 separate devices to a Linux guest, and I can have up to 33 I/O operations active from the perspective of the Linux guest. We may collide when we get back to actually going out to the disk, but CP can try to minimize the seek time to get the best response from the disks, and gets to apply the cache both in the controllers and in the VM MDC facility across all those virtual devices simultaneously. This is great for one virtual machine -- if you have several virtual machines all banging away, CP has knowledge of what's happening system-wide; the individual Linux guests can only see their own virtual environment. The likelihood is that some of the I/O from one machine overlaps I/O done by another virtual machine, which increases the probability that a particular physical block will already be in MDC, and thus we skip the trip to the physical disk. This approach keeps the isolation of the virtual images, but still lets the entire environment benefit from activity in the various guests. For you OS/390 folks, think of the difference between doing a lot of seeks on a file with a single huge extent and doing the same with a file with multiple extents. Kind of the same idea here.
