Well said by John.

I'd add one minor disclaimer.

Backups and restores ARE different when dealing with user volumes.

Assuming that you include the ;DIRECTORY option on your backup, you would
need to also include:

;onvs=mpexl_system_volume_set,uservol1,uservol2,...

On any future system install, you would need to re-create the user volume
set environment with VOLUTIL and restore the properly-stored directories
from backup before initiating the restore.

I still think that this and other inconveniences would discourage me from
using user volumes in an environment already protected by hardware mirroring.



At 01:24 PM 2004-03-10, John Clogg wrote:
>One of the main benefits of private volumes is fault isolation.  If a disk
>drive in a private volume set were to fail, you would only need to restore
>that volume set, rather than doing a complete install of the whole
>system.  Since you have mirrored arrays, that benefit diminishes in
>importance.  I don't find system administration to be enough more
>difficult with private volumes to even consider as a factor.  About the
>only consideration is creating and deleting groups.  For each group you
>create you have to do two NEWGROUP commands - one to add the group to the
>system directory, and one for the volume set directory.  There are command
>files available on Jazz that automate that extra step for you, if you find
>that problematic.  Backups and restores are no different with private
>volume sets.
>
>Yes, you can manipulate class names without a reload.  Others have already
>provided instructions.
>
>Regarding maintenance of your Nikes, you have three choices:  (1) HP will
>probably still support them on a time and materials basis, (2) You can get
>a maintenance agreement with a third-party support organization, or (3)
>Stock you own set of spares.  In my opinion, the best answer is either
>number 2 or a combination of 1 and 3.  In other words, have spare drives
>available to replace any that fail, and pay T&M charges if a more involved
>repair is needed.
>
>One more thing I want to comment on: Craig characterized XM as a write
>cache.  I disagree.  XM is essentially a log of physical transactions in
>progress, whose purpose is to allow the reversal of incomplete
>transactions in the event of a system failure.  Disc caching happens
>regardless of whether you have XM enabled or not.  If having multiple
>instances of XM does anything for performance, it's because of increased
>parallelism and less frequent checkpoints.
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

-------------------------------------------------------------------------------------------------
Gilles Schipper
GSA Inc.
HP System Administration Specialists
300 John Street, Box 87651   Thornhill, ON Canada L3T 7R4
Voice: 905.889.3000     Fax: 905.889.3001
email:  [log in to unmask]  web: http://www.gsainc.com
-------------------------------------------------------------------------------------------------

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *