[Info-vax] Initializing a new disk, need some pointers for options

Hein RMS van den Heuvel heinvandenheuvel at gmail.com
Thu Oct 31 00:54:23 EDT 2019


On Wednesday, October 30, 2019 at 6:53:38 PM UTC-4, cgill... at gmail.com wrote:
> So I've been supporting a VMS machine for almost 20 years now.  As all things VMS, it just sits in the corner and runs.  Today, the application disk started throwing DIRALLOC errors.  I ran into this like 10+ years ago, I understand why it happens.
> 
> The VAX now runs in a VM, so I just need to create another disk container initialize it and go.  But, there are some options I'm curious about.  The documentation is accurate, it just doesn't fill in a lot of why and the nuances.
> 
> The existing application shoves all of it's files in the root folder.  The application has accumulated 150K files.
> 
> /Headers
>   According to the doc, I should pick something along the lines of the # of files
>   on the disk.  So, 150K?

Yes, this is the more/most important switch.  to pre-allocate INDEXF space you know will be needed anyway. I'd go 25%  - 50% larger than the current size (number of files)

> /Index = location
>   Does it really matter?

No, not likely. It only matters for volumes mapped to a single physical, spinning disk. In that case, considering that the headers are frequently visited, sometimes as often as the data blocks, you can minimize the average seek distance/time by placing it in the middle or thereabouts (for a largely full disk)



> /Maximum_Files= nnn
>   This is pretty obvious.

This value does not 'cost' anything. It could potentially protect you against run-away application, but when it does - it is too late and fatal.
I'd leave it at the default ( 2 clusters/file ) or set to max ( 1 cluster/file) for disks with mostly/only small files.

>From the help " The /MAXIMUM_FILES qualifier does not reserve or create
        space for new file headers on a volume. The file system
        dynamically allocates space as it is needed for new headers."

You may want to look at /CLUSTER.
For RAID storage is will be a somewhat beneficial if it divides evenly into a stripe or is a whole multiple of the stripe-size (and/or cache line)

Are those 150 K file in a single directory? That may seriously impact directory growth/shrinks. 
You may want to test using a search list of a smaller directory for files that are currently being created/deleted and a larger directory holding the bulk of the file, perhaps those more than a year old?
Search list are transparent for most, but not all, applications

hth,
Hein
 



More information about the Info-vax mailing list