On Friday, 03/26/2010 at 12:26 EDT, "Schuh, Richard" <rsc...@visa.com> wrote: > As evidenced by the statements in the post repeated below, there is discussion > of the offset from real cylinder 0 to real cylinder 1. That implies a protected > cylinder 0 and necessitates CCW translation, does it not? As you stated, it is > slower, but not as much slower as it was in VM/370 Release x (you supply the > value for x).
With few exceptions, all I/O goes through CCW translation. Non-fullpack minidisks go through cylinder translation and limit checking. "Fast CCW translation" was a VM/XA invention, I think, wherein dasd channel programs that don't require excessive CP "handling" can take an expedited path through the translation code. > The whole discussion seems to have been about protecting real cylinder 0, and > whether the overhead involved in doing so would be too onerous. The sentiment I > get from the posts is that (a) it is not too much of a burden, and (b) the > protection afforded by protecting the cylinder is well worth the price. The > only way to know for certain if that is true for you is to experience a failure > due to not protecting the cylinder and see what it takes to recover. Or you > could take out an insurance policy by protecting the volume labels. It is a > question of risk vs. reward. You said it better than I did. CCW translation speed is a red herring and only serves to distract from the far more important system management issues: It's ok to let guests play with cylinder zero as long as you can tolerate mangled labels (Backup/Restore/DR?) and you take the steps needed to protect your system and your users from malicious guests. (All unprivileged guests are considered to be Evil, doing their best to spread mayhem and Corruption. Fortunately, z/VM is up to the task.) Alan Altmark z/VM Development IBM Endicott
