[Info-vax] Move SECURITY.AUDIT$JOURNAL off the system disk?

[Phillip Helbig---undress to reply]

In article <4e3bb8c5$0$305$14726298 at news.sunsite.dk>, "R.A.Omond"
<Roy.Omond at BlueBubble.UK.Com> writes: 

> On 05/08/2011 09:37, Phillip Helbig---undress to reply wrote:
> >
> > Basically, there are two reasons for moving files off the system disk:
> > in order to have common files among several system disks and to save
> > space/reduce load on the system disk.  Of course, in some cases both
> > reasons might be valid. [... big snip ...]
> 
> Am I alone in thinking "why go to all that bother ?"
> 
> In all the systems I'm semi-looking-after (at several customer sites
> throughout the UK), the system disk is (a) zillions of times big
> enough, and (b) is probably the lightest loaded disk in the whole
> setup (and this does include development systems).
> 
> Phillip, I think you're bordering on obsessive.

Maybe, but not in this respect.  :-)

First, my system disks are just 4.3 GB.  I am using my 9.1-GB disks for 
other things.  Yes, I would like to replace the 9.1-GB disks with larger 
ones and free up the 9.1-GB disks for use as system disks, but at the 
moment the only SBB disks I have which are larger than 9.1 GB is one 
36.4-GB disk.  I am happy to give any SBB disks a good home.  :-)

Second, my main concern is not so much reducing the load on the system 
disk as maintaining just one group of files (SYSUAF etc) rather than one 
group on each system disk.  Each node in my cluster has its own system 
disk, both since I don't have the hardware to have dual-ported disks and 
also so that I can do rolling upgrades (with the possibility to 
downgrade), test things on only one node etc.  Getting the 
cluster-common files off the system disk saves a lot of work.  Also, 
once the "personality" of the disk is gone, one can easily copy a system 
disk for use on another node, even in another cluster.  If one has many 
layered products etc installed this makes a lot of sense.  Essentially, 
this is just the same as SYS$COMMON vs. SYS$SPECIFIC; I'm essentially 
adding one more link in the chain.

(It would be nice if SYS$SYSROOT included, say, SYS$CLUSTER as an
additional translation.  All one would then have to do is define the
logical name SYS$CLUSTER and we would have the same comfortable
functionality for several system disks in one cluster as we now have for
several nodes booting from one system disk.  Of course, one could take 
this approach, but I am not sure to what extent it is supported.  Also, 
if it is the last link in the chain, this would mean that files of the 
same name could not exist further up the chain.  By explicitly defining 
a logical name to point to one location (off the system disk), the 
original files can stay where they are so that some minimal 
functionality is possible when only the system disk is connected.)

I have had the stuff mentioned in SYLOGICALS.TEMPLATE set up for a long
time.  Recent motivation to do some more work here, apart from just
wanting to have a nice setup, is that I wanted more space on the system
disk now that I have a whopping 2 GB of memory on one node.  Since I
want to avoid the SPOF of a single physical disk and don't have any
controller-based RAID stuff, all my disks are HBVS.  This means that I 
have to have the dump file on the system disk (which also means I can't 
use HBMM, but I can live without that for now).  Even with a compressed 
dump, that is a fair chunk of a 4.3-GB disk.  Maybe I could do without a 
dump file, but it might be useful to have one if something goes wrong.