The simple MW approach is surely wrong, it will not create a PAV
environment: Linux will think it has 3 different devices, accidents will
happen.

MDC will avoid the IO; Control Unit cache hit is still IO as concerned for
the z Series, but here PAV would help.  AFAIK, PAV will not help if the
concurrent IOs are not satisfied mostly from the control unit cache: the
real disk can only handle one IO anyhow.

I never implemented PAV (my former customer didn't have PAV enabled for the
VM disks: it wouldn't help with DB2 nor SFS, and that's what they used
heavily).  You need to use the MDISK's MINIOPT directory record to tell CP
to create a PAV group; keyword PAVALIAS.  This way Linux will recognize all
addresses as a PAV group.   My guess:
  MDISK 391 3390 1500 500 VOL001 M       (I removed the W)
  MINIOPT PAVALIAS 1391 2391
would create 391 as base and 1391 plus 2391 as PAV alias addresses.


2009/7/2 RPN01 <[email protected]>

>  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" <[email protected]> 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 <[email protected]>
>
> 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?
>
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to