Conference vaxaxp::vmsnotes

>problem is not so like the contiguous free space problem as the "map area word
>in use" is 12 only.

Yes it is. This has nothing to do with the number of mapping pointers in use.
In this case the XQP has to extend the directory file, and it lacks contiguous 
space on disk to do so.

Defrag the disk.

Jur.

   As .1 says, defragment the disk.  Use BACKUP. 

   The "map area words in use" from DUMP/HEADER, halved, is the number
   of fragments the file is presently in.  Further down the same display,
   you can get an idea of the various sizes of the fragments.

   Look for files that grow consistently over time -- log files, indexed
   files, etc, -- and determine if increasing the default extent size on
   the file(s) or process(s) will reduce the fragmentation.

   I'd seriously onsider adding disk storage -- disk storage is presently
   relatively cheap, and consistently sufficient free space, and the
   partitioning of scratch and volatile storage files from the static
   and incrementally-growing files can help avoid or greatly reduce the
   fragmentation.  (Some amount of file fragmentation is entirely normal
   and expected -- and good -- behaviour.)

   As directory files are expected to be contiguous, a fragmentation value
   of six (based on a map area value of twelve) would tend to indicate a
   very large directory file -- please encourage the customer to use
   multiple subdirectories, and -- when creating large numbers of files
   in a directory (under program control), to generate filenames that
   would place the new filename(s) at the end of the directory.  Both
   techniques can improve the performance of the directory files.

   --

   (When asking questions, it's also often useful to include the OpenVMS
   version and the platform.  And in this case, the total size of the
   directory -- entries and blocks -- would be of interest.)

    re .1
    
    Then how can I explain that other files can be created in the same
    directory? Is there any kind of hashing/grouping of file in the
    directory so that adding some file caused directory file to expand
    while adding other files will not?
    
    Regards,
    Mickwid.

    Directory files are not dense (looking at the records. looking
    at the concepts come might disagree :^). Records are stored sorted 
    and 'blocked' in 1 block units. If one removes a directory entry 
    then the space for the entry (the whole record if there is only one
    version) becomes available for use in that block roughly speaking 
    only for entries with a similar name. Once the last entry for a block
    it removed, the whole block will be shuffled out of the directory.
    This will make room for any new name.
    You may well find that
    	- you _can_ add the impossible entry be deleting / removing 
    	  files with a very similar name (lots of leading characters
    	  in common
    	- you can NOT add many more files with a name starting with
          the same characters as you used for the succes trials
    	- you _can_ add the impossible entry by deleting a series
    	  of names close to one-another, but distant from the test
    	- you have no more problem at all because someone deleted
    	  a large contig file.
    
    To experiment with all this I recommend $DUMP/DIRECOTRY
    and thje freeware tool DFU REPORT diskname
    
    Hein.
    
    

re .2,.0
    
>   The "map area words in use" from DUMP/HEADER, halved, is the number
>   of fragments the file is presently in.
    
    This is not strictly correct.
    
    The map area words in use is the number of 16-bit words in the map area
    that are in use. How many fragments this equates to depends on the
    format that each retrieval pointer is using. In the most compact format
    (format 1 = 1 longword = 2 words = 1 retrieval pointer) the claim is true
    but if format 2 is in use e.g. extent has length exceeding 255 blocks
    (a not uncommon situation) then 1 retrieval pointer = 3 words.
    Similarly for format 3, 1 retrieval pointer = 4 words. Obviously if
    there is a mix of formats in use in one file header then there is no
    simple conversion from "words in use" to "number of extents".
    
    For directories, of necessity being contiguous, the map area words in
    use *must* be 2, 3 or 4 (for exactly 1 retrieval pointer) so I can only
    assume that the quoted value applies to some other file e.g. INDEXF.SYS.

    If you want some hard figures DFU is the tool to use.
    The REPORT <device> command will tell you quit a few
    things, such as a judgement of the fragmentation level,
    and the largest contiguous free space. If this last figure
    is more or less the size of the directory then you are in
    trouble. Extending this directory will not succeed as the
    XQP is no longer able to allocate enough contiguous space.
    
    DFU also has an option to compress directories , this may
    help you out for the time being. However, the bottom line
    is that you need to defragment the disk.
    
    Rgds, Ton