CMS IO can indeed profit from PAV: CP knows how to look at PAV aliases when a disk is busy.
SFS is another story: the SFS SW knows where its minidisks are located. It will not attempt to launch an IO to a volume to which it has an active IO. So: if you have multiple SFS servers on a given PACK, SFS will profit of PAV, else it won't. (and, I do encounter many installations where people place all MDISKs of a given SFS on as few disks as possible. It is better to spread). DB2 is yet another story: if you use dataspaces, DB2's IOs are performed by CP's paging routines, so no PAV.... Else I think the same rules as for SFS apply. 2010/12/20 George Henke/NYLIC <[email protected]> > Why would you NOT want PAV for CMS mds? > > The IO Supervisor has not kept up with the hardware. > > It still thinks of a disk device as a "spinning platter" when in fact it is > a rank of RAID devices striped over numerous HDs and cached in a disk > controller from where it is actually being read thereby permitting multiple > IOs to the same device number.. > > The problem is that the IO Supervisor checks the IOB Busy Bit before > issuing a SIO and, if it is on, unnecessarilly suspends the SIO until the > device is idle. > > Instead of changing the IO Supervisor, IBM has opted to fake it out by > defining alias devices for the same device number in PAV. > > Since most workloads these days are still IO bound, why would you still > want to unnecessarilly "single thread" IO, why would you NOT want PAV on CMS > mds, SFS, or whatever? > > > > > > *Mike Walter <[email protected]>* > Sent by: The IBM z/VM Operating System <[email protected]> > > 12/20/2010 11:33 AM > Please respond to > The IBM z/VM Operating System <[email protected]> > > To > [email protected] > cc > Subject > General CMS minidisks and SFS on PAV DASD? > > > > > We've always avoided using PAV volumes for general user (non-fullpack) CMS > minidisks. Instead we've only used DASD defined as 3390-3 so that I/O > queueing is minimized. That choice was in part due to management > decisions. > > Over the past weekend we needed to move some z/VM DASD quickly -- and the > target DASD was already defined as PAV DASD. > > The z/VM CP Planning and Administration manual clearly states that "z/VM > Paging and SPOOLing operations do not take advantage of PAV." (no argument > here). We'll still plan to keep page and SPOOL volumes on non-PAV 3390-3 > DASD. > > But the same manual also states that "When multiple CMS volumes are > defined on a real PAV volume, I/O operations by CMS can be concurrently > scheduled on any real PAV base or alias subchannel by z/VM. The CMS user > does not need to take any action for this to occur." > > Well, that's "book larn'in". Can anyone provide real-life results of > using PAV volumes for general-purpose CMS user minidisks, and... for SFS > filespaces? > > Do you see real I/O improvement for those apps? If so, the next time > we're asked we might recommend larger 3390 volumes, mod 9's or 27's > (depending on the number of available paths) to permit larger minidisks > without SFS overhead, and improved SFS performance. > > Thanks! > > Mike Walter > Aon Corporation > The opinions expressed herein are mine alone, not my employer's. > > > > The information contained in this e-mail and any accompanying documents may > contain information that is confidential or otherwise protected from > disclosure. If you are not the intended recipient of this message, or if > this message has been addressed to you in error, please immediately alert > the sender by reply e-mail and then delete this message, including any > attachments. Any dissemination, distribution or other use of the contents of > this message by anyone other than the intended recipient is strictly > prohibited. All messages sent to and from this e-mail address may be > monitored as permitted by applicable law and regulations to ensure > compliance with our internal policies and to protect our business. E-mails > are not secure and cannot be guaranteed to be error free as they can be > intercepted, amended, lost or destroyed, or contain viruses. You are deemed > to have accepted these risks if you communicate with us by e-mail. > > -- Kris Buelens, IBM Belgium, VM customer support
