Your response verifies what I¹d thought was happening, but doesn¹t address the whole ³multiple writable minidisk² quandary.
I¹m considering something like the following: USER LINUXGUEST MDISK 391 3390 1500 500 VOL001 MW LINK * 391 1391 MW LINK * 391 2391 MW Which would give me three virtual devices all pointing to the same minidisk within the Linux guest. First big question: Have I shot myself in the foot? Common z/VM wisdom says that multiple write enabled links to the same minidisk lead down a slippery slope to disaster. But would that be the case here? Second big question: Would PAV see the various I/O requests and assign them to separate PAV aliases, allowing for better thorughput to the device? I¹m thinking that, if I can get past the first question, then the second would be ³yes². One thing you didn¹t mention in your response is that, hopefully, many of the requests can be satisfied from cache, either via MDC or control unit caching, avoiding the actual I/O. The thing that PAV and the multiple minidisks would give you is the ability to get those I/Os started sooner than with a single path in Linux. -- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 7/2/09 12:15 PM, "Kris Buelens" <kris.buel...@gmail.com> wrote: > I don't have a full answer to your question. But I want to avoid a > misconception: > * mutipathing in z Architecture means a device can be reached by more than one > path, most often this means more than one CHPID leads to the device, and each > CHPID is connected to a different controlunit. > * Without PAV: when a device in handling an IO, other IOs will be queued, for > example by CP (reported by Pefkit). But also Linux, SFS, DB2VM, xxx know that > classically a device can handle one one IO, and will queue other IOs (not > reported by Perfkit). > * PAV at the other hand makes it possible to have more than 1 I/O active on a > single device. PAV is kind of a ly: a given device address can still have > only one IO active; with PAV one assigns alternate device addresses to a > single device. > * With PAV: when CP gets IO requests from different users for the same device, > it will look for a free PAV address and may be able to launch it instead of > queueing it. Linux -as far as I know- is also PAV aware, so it can launch > more than one IO on condition that one gives it PAV addresses, otherwise it > won't be able to exploit it. > > 2009/6/30 RPN01 <nix.rob...@mayo.edu> >> Before I put something huge together to test this, I thought I¹d pass it by >> all the experts. >> >> Linux has the ability to multipath, and z/VM supports multipathing via PAV. >> There¹s lots of documentation and studies showing that you can attach / >> dedicate the PAV addresses to a Linux LPAR or guest, and implement >> multipathing to DASD devices. This seems to be fairly clearly researched and >> understood. >> >> What I¹m wondering about would be multiple links to the same minidisk >> (partial 3390, as opposed to a full volume) backed by a PAV multi-address >> environment sustained by z/VM. Would it help I/O throughput to have multiple >> MW minidisks set up in Linux as multipathing, if they were on a DASD with PAV >> enabled, and having several physical addresses? Are there any got¹chas to >> this configuration? Any reason why it wouldn¹t work?
