INIT params for disk to build on-disk save sets - VMS

This is a discussion on INIT params for disk to build on-disk save sets - VMS ; On Oct 23, 4:49 pm, Hein RMS van den Heuvel wrote: > On Oct 23, 4:27 pm, AEF wrote: > : > > > I will primarily have just one large file on this disk at any given > : ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: INIT params for disk to build on-disk save sets

  1. Re: INIT params for disk to build on-disk save sets

    On Oct 23, 4:49 pm, Hein RMS van den Heuvel
    wrote:
    > On Oct 23, 4:27 pm, AEF wrote:
    > :
    >
    > > I will primarily have just one large file on this disk at any given

    > :
    > > disk? (For those of you who are too young to remember, these disks are
    > > 2 GB in size. Or more accurately: 4110480 TOTAL BLOCKS.)

    >
    > I'm old enough... 7200 rpm, narrow scsi, big then, very small now.
    > You are better of with a $99 500GB USB drive if you can hook that up!
    >
    > > OK, so I was thinking of large value for /CLUSTER.

    >
    > Yeah sure... like 512.
    >
    > > large value for /EXTEND, maybe 10000

    >
    > Certainly, line 64000


    Wait a minute. Doesn't this mean that the extend value would be
    512*64000=32768000 blocks? This is larger than the disk.

    Maybe I should leave the EXTENSION value at its default of 5 and
    specify a huge cluster size of 10000, 20000, or 40000 (has to be .LE.
    the size of the disk, which is 4110480 blocks).

    BTW, the File Applications manual says that a cluster may or may not
    be contiguous. I assume this means that a cluster may or may not span
    two adjacent tracks, no?

    >
    > > small value for /HEADERS

    > Sure... 100?


    On further though, I may as well leave it at its default of 16.

    > > medium value for /MAXIMUM_FILES

    >
    > Sure... 1000?


    Someone pointed out that the index file bitmap contains one bit per
    file header so that I may as well use 4096. It shouldn't really matter
    much.

    >
    > And maybe add /INDEX=BEG


    OK.

    The qualifier /INDEX=BEGINNING means the outermost cylinders, right?
    Just curious.

    >
    > > What do y'all think? Is it even worth bothering with?

    >
    > I would, but I would not expect much from it other then no longer
    > having the think whether I should have tweaked it some. :-). Piece of
    > mind.


    Well, I think the EXTENSION value (measured in blocks) is important,
    at least.

    >
    > Hein.


    Thanks!

    AEF

  2. Re: INIT params for disk to build on-disk save sets

    HELP INIT and go though each parameter to see if it would make sense to
    tune it manually.

    /CLUSTER_FACTOR is also one you could grow. Can anyone provide how this
    would be limited ? (buffer allocations ?)

    /EXTENTION is an obvious one

    and /MAXIMUM_FILES + /HEADERS

    (this might require some discussion on C.O.V. since you are likely to
    have a very small number of files, but possibly a larger number of
    headers if the files are extended a lot while they are being written to).

    there is also /DIRECTORIES which is used to calculate the size of 000000.dir


    But you should also look into "older" parameters if you have an older
    VMS version such as /ACCESSED and /WINDOW . These two were primitive
    caching parameters and for a small number of files, you could end up
    caching the disk's directory structure and file pointers in memory if
    those are large enough.



  3. Re: INIT params for disk to build on-disk save sets


    On Thu, 23 Oct 2008 at 13:12 -0700, AEF wrote:

    > I have a system

    Mean as she can be!
    >


    --

    Rob Brown b r o w n a t g m c l d o t c o m
    G. Michaels Consulting Ltd. (780)438-9343 (voice)
    Edmonton (780)437-3367 (FAX)
    http://gmcl.com/


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2