HP3000-L Archives

March 1996, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Denys Beauchemin <[log in to unmask]>
Reply To:
Date:
Fri, 1 Mar 1996 09:48:36 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
In a message dated 96-03-01 00:29:33 EST, [log in to unmask] (KLRenk) writes:
 
>I have heard and seen articles about just making LDEV 1 the only volume in
>the system volume set and creating a different volume set for the rest.
>What is this groups feelings on segregating LDEV 1.   Is it worth it?
>
>I am in the process of upgrading our hp3000 to 939ks and deciding whether
>or not to do it.   LDEV 1 is a 2db drive.  Any thoughts would be
>appreciated....
>
>
 
Everyone on MPE/iX uses volume management, it is just that many sites only
have MPE_XL_SYSTEM_VOLUME_SET as their lone VS (Volume Set).
 
I have preached the multi-vs approach since the early days of MPE/XL.  I
wrote papers about it and I gave talks about it.  I even practiced what I
preached.
 
Advantages:
 
1- Better overall performance due to decoupling of the XM checkpoint
processing.  This has really come of age with iX 4.0 (I believe) when
simultaneous XM recoveries could not take place during boot-up.  iX 3.0 (I
believe) introduced the idea of multi-tasked checkpoint processing using PIN
9 to monitor and launch various processes. Real neat.
The checkpoint processing could now be spread across time thus reducing the
hit on the system.  The SVS checkpoint processing only becomes concerned with
system things and no longer worries about IMAGE and KSAM files.  The idea
that there is a performance penalty with multiple UVS' is a holdover from the
days of MPE/V where volume sets where installed as an afterthought.  In
MPE/iX, they were designed in from the beginning.
 
2- Better resiliency.  If you have multiple UVS (User Volume Sets) you are
less hurt when you throw a disc (so to speak).  If the disc is part of SVS
(MPE_XL_SYSTEM_VOLUME_SET) you may be faced with an INSTALL but only for that
(relatively) small volume set.  If the disc is part of a UVS, then only that
volume set goes down, the rest stays up.  You can then deal with that UVS
while the other UVS' remain unaffected.
 
3- Better disc space management.  You can assign UVS' to different
applications and let the application leaders manage and plan for new disc
requirement, without having to worry that some hoser will squirrel away a
couple of gigabytes of disc from the common pool.
 
4- If you have multiple systems, with multiple UVS', you can, move a UVS from
one system to another, in case of catastrophy.
 
5- You can isolate the SVS and keep the users from putting file on that
volume set especially on LDEV 1, the busiest drive of the system. When time
comes for UPDATE, looking for space on LDEV 1 is rendered less difficult.
 
6- You cannot mirror MPE_XL_SYSTEM_VOLUME_SET.
 
One big caveat is that you must keep up the number of spindles on the SVS.
 Transient Memory resides ONLY on the SVS. I also believe that holds true for
spooler files but I am not sure at all.  Also, you do not want a disk array
as LDEV 1!
 
If your iX system only has 4 or less disc drives, you may not want to use
UVS.  With more than that, you need to look at it.  If you have more than 7
or 8 disc drives and you only have an SVS, you are doing yourself, as a
system manager, and everyone else a disfavor.
 
Warning, an INSTALL is required to move from a single SVS to SVS and multiple
UVS, along with some careful planning, but it is worth the work. You will
lose space with each volume set as UVS require about 400,000 sectors (last
time I checked) each on the master drive of the set. This is for the
directory structures and the XM logfiles for that UVS.  Hint: keep your
fastest and most dependable discs in the SVS and as the master drives for the
UVS.
 
My friend Steve Cole will, it is hoped, expound on this issue more.
 
Kind regards,
 
Denys. . .

ATOM RSS1 RSS2