There is maybe some misunderstanding: (leaving out PAV a while) a device can handle only 1 IO at a time, guests know that, CP too. So indeed a linux will not send a new IO if the previous one to that disk hasn't ended yet, the guets will queue it. With several guests with minidisks on the same disk, CP will queue the requests. Multipathing doesn't change that. Multipathing helps in cases where the device is not busy, but the channel or control unit is.
PAV simplified: with PAV, you make appear a single disk as if it were many disks, but for each PAV address the old rule is still valid: one IO at a time. If you guest is PAV aware, it can also avoid queuing, if not, putting many guests on the same volume and let CP exploit PAV can improve IO rates. 2010/3/25 RPN01 <nix.rob...@mayo.edu> > Another point I’ve not seen mentioned, and I’m not sure if it’s true or > not... > > Given a dedicated volume to a Linux guest, won’t the guest start only one > I/O to the device at a time, and wait for it to complete? If you break up a > larger volume into several minidisks (like a mod 27 into mod 9’s) aren’t you > allowing the z/VM multipathing to do its job more efficiently, even if you > give all the smaller volumes to the same Linux guest? > > Like I said, I may be totally off base, but this is the impression I’ve > had... > > -- > 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 3/24/10 2:38 PM, "Scott Rohling" <scott.rohl...@gmail.com> wrote: > > I would not recommend using DEDICATE -- why would you do that rather than > use minidisks? What you need to be aware of is that if you DEDICATE -- > Linux will label the DASD -- and that's what you'll see at the z/VM level -- > and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, > etc...). Also - if you dedicate - you can't use things like DIRMAINT do > manage your dasd and keep things in pools, etc -- you have to manage it all > yourself. > > On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) < > terry.mar...@cms.hhs.gov> wrote: > > Hi > > I have a question. What I have been doing up to this point for a new > z/Linux guest build is, not necessarily in this order and does not > necessarily include all steps but, > > Crave out the DASD for the z/Linux guest > > Init the DASD using CPFMTXA putting a label on the disk > > Setting up the Directory entry for the new guest, which includes specifying > the MDISK for all of the DASD for the guest. > > We back up our z/Linux guests on the z/OS side with DFDSS. > > My question is since when we Kick Start the new z/Linux guest and it > initializes the DASD during this process is there any compelling reason for > me to initialize the DASD up front before the guest is Kick Started for the > first time basically doing a double INIT? > > If not I assume then I would replace the MDISK statements in the Directory > entry with DEDICATE statements for each one of the DISKS. We do not share > DASD between guests here so what is defined to the guest belongs to that > guest only. Is there anything to be aware of by changing to DEDICATE > statements from MDISK statements? > > My only concern is with the DFDSS backups that I do on the z/OS for the > guests. I am not sure if it matters or not to DFDSS whether the pack was > initialized via CPFMTXA or z/Linux during the kick start process? > > > *Thank You, > > Terry Martin > Lockheed Martin - Citic > z/OS and z/VM Performance Tuning and Operating Systems Support > Office - 443 348-2102 > Cell - 443 632-4191 > > * > > > > -- Kris Buelens, IBM Belgium, VM customer support
