On Thu, Sep 17, 2009 at 10:55 PM, Kris Buelens <[email protected]> wrote:
> Using V-disks: less I/O involved: no CP format, and CMS format doesn't need > to write nK data blocks all over the disk. But, V-disk pages are considered > as shared storage by CP. So, V-disk pages may stay longer in real storage > than other user pages. We once used large V-disks as sort work area, > performance of the system was degraded. This was in the VM/ESA R2(?) era, > with less real storage available than in a modern system. See http://www.urban-myths.com/vdisk ;-) Unlike VDISK that comes out of the directory, the disk resulting from a DEFINE VFB-512 command is not considered shared. But still, private VDISK is only harvested in 2nd demand scan while idle CMS users are target in 1st scan already. And it is easy to be fooled because CMS voluntarily gives up pages when it does not need them anymore (which we don't have for VDISK - though the CMS allocation strategy did get adopted for that). You can't blame CP when the user himself gives up the resources. So if your system is wealthy enough on storage that you get all from 1st scan or less, VDISK remains resident. And is that a bad thing? VDISK really is made from the same bytes as virtual memory. If you give a 12M CMS user a VDISK of 100M, you give the user about 10 times as much memory resources to do his work. That's not something you do without measuring. If your system was already pretty full, I would expect it to make performance worse for the rest of the users. And if you do this a lot, z/VM will be thrashing and every user suffers. The thing that lacks is DIAG10 for VDISK. When you erase the files on the VDISK, CP will still retain the data (until you detach it). For CMS workload, my strategy is to use VDISK only for short-living temporary data (we used it in CMS Batch for example, and for application EXECs that would detach the disk pretty soon again). Note: this is completely separate discussion from using VDISK for swap space in Linux. The CMS background explains why some VM folks initially were suspicious to use VDISK for Linux, because they assumed CMS workload patterns. Most z/VM systems today however (especially with Linux) run in 2nd scan or even emergency scan all the time where this is not an issue. Rob
