[Info-vax] set fil/enter on a dump file

[Phillip Helbig---undress to reply]

In article <5159b13a$0$9072$815e3792 at news.qwest.net>, George Cornelius
<cornelius at encompasserve.org> writes: 

> >>Be aware that having page, swap, and perhaps dump files on
> >>a boot disk interferes with merges, but I have forgotten
> >>some of the details.  Essentially you get full merges
> >>on the system disk when you might not otherwise expect
> >>them.  You can ignore this, but it does impact
> >>performance when it occurs.  
> > 
> > I haven't heard of this.
> 
> Well, I don't have experience beyond 7.3-2, 

Neither do I.  (If all goes well, I will upgrade via 8.3 to 8.4 at the 
beginning of May.)

> but in my
> environments when a node left the cluster I generally
> found it was unable to completely dismount the system
> disk when it had one or more of those files present,
> the result being a system disk a shadow merge.

OK, but I think this goes for a system disk in general, even without 
swap or page files on it.

> >>If you have minimerge
> >>functionality (same as HBMM?) it is possible that that
> >>improves things.
> >
> > HBMM requires that the dump file is not on the system disk.  However, it
> > cannot be on a non-shadowed disk.  Since I don't have any
> > controller-based RAID, I haven't set this up.  I suppose I could use 
> > just a single non-shadowed disk and take my chances that the disk goes 
> > bad just when a dump is needed. 
> 
> I don't believe it is controller based at all.  Controller based
> minimerge operations have been around for quite some time, but they
> may have only been for the older - CI and DSSI based - controllers,
> and did not help much, if at all, for multidatacenter clusters.

No; misunderstanding: HBMM requires the dump file to be off of the 
system disk.  It also cannot be on a shadowed disk.  Thus, my options 
are to have it on a single physical disk or to have it on some sort of 
controller-based RAID disk.  Since I don't have the latter, my only 
option would be to have it on a single disk, which is obviously a single 
point of failure.