[Info-vax] what is a good value for /CLUSTER_SIZE? (INITIALIZE and qualifiers)

[Dave]

On Feb 6, 8:16 am, Hein RMS van den Heuvel
<heinvandenheu... at gmail.com> wrote:
> On Feb 6, 2:17 am, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
>
> undress to reply) wrote:
> > In article
> > With DDS, presumably if I initialise a new, larger disk to add to the
> > shadow set, its values of /HEADERS and /CLUSTER_SIZE won't be
> > overwritten by the shadow copy.  Or will they?
>
> Shadowing works at the LBN level and is blissfully unaware of
> clustersize, storage bitmaps, indexf.sys and so on.
>
> > becomes difficult to use DDS and DVE to grow a shadow set to a larger
> > size with sensible values for the cluster size.
>
> Cluster_size is not really device size dependend, more file size.
> But on a large disk the tendency is too be willing to waste more and
> pick larger to ease the system
> If you know you are going to grow, then you should design for the
> final size.
>
> > > and your are fine pre-allocating 450,000 headers (1/4 GB) on a 9GB
> > > drive. Fine by me.
>
> > Right; that's not too much, especially when the consequences of having
> > it too low are bad.
>
> The consequence of /MAX_FILES too low are nasty: hard wall. That param
> is next to free: 1 bit per file.
> /HEADER is just a pre-allocation and with the current INDEXF.SYS
> growth algorithm less, or no, issue.
>
> > Presumably Oracle Classic and not Oracle Rdb?!
>
> Yes. The Oracle classic build environment is nasty, unixy, with many
> many files and links.
>
> Hein

I have yet to hear any downside to allowing the expansion size limit
to be the maximum, (1 TB, although I think this has just been
increased to 2TB).    Neither do I really see any justification for
playing around with /HEADERS since this only defines an initial
allocation.    I guess that it would be possible to present an
argument for why messing around with the value for /CLUSTER_SIZE, is
justified, but that would require that you know that the file size
distribution on the volume is never going to change.

It is still possible to be mounting and using small volumes (if you
happen to be using EVA, you can pretty much have any size volume you
want.   Im sure there is a minimum, but I dont know what it is these
days).     In general however, my personal inclination is to
initialize new volumes to the maximum expansion size (/headers=default
and /clust=default [=8]}and then set the volume to maximum physical
size

$  init/sys/limit[...]    <device>  <label>
$  mount <device>  <label>
$  set volume /size <device>
$  dismount <device>
$  mount/sys DSAn/shad=(<device>,<device2>)  <label>  <log_name>

This results in a shadow set that is fully capable of DDS (providing
the new device is larger than "Logical Volume Size" and also DVE, upto
the maximum potential volume size.

just my 2 cents worth.

Dave.