What I've learned (by study and experience - see an earlier thread) is that directory requires contiguous space. I deduct from observations that the file system (XQP, to be exact) will locate new files based on a kind of hashing mechanism (correct me if I'm wrong). This _might_ mean that when a calculated slot within the directory-file is already occupied, it's very well possible that the new slot will be at the end of the directroy file - expanding it into the next cluster if needed. For that reason, I doubt that limiting a directory's size is actullay useful, except you do not create any more files within it.
If you are so short of room on a disk, you definitely will run into trouble. Suppose you create a new file, and it will be placed at the end of the directory, it's possible the directory needs to be expanded into the next cluster. If no room is available at the curent disk-location, the file will have to be moved to a place on that disk that holds the whole allocated size as contiguous space. If that fails, you'll end up in an error. Or, expansion of the directory succeeds but there is too little room for the file to be allocated.
Willem Grooters OpenVMS Developer & System Manager
Why? Nothing better to do? What is the real problem you are trying to solve? What is the magnitude of the real directory (over) allocation you are addressing? You do knwo XQP/RMS will use the pre-allocated space for quicker future additions right? So shrinking is good for read-only directories, but the price to get is wrong is high!
Lokesh> I do NOT want to use backup/restore option.
Right. You don't want to because it is very wastefull, and potentially slow. The VMS native sollution for this is RENAME. This will NOT move the DATA, it WILL not create new files, it will just shuffle directory entries and tightly pack them as you go.
Lokesh> I increase the the directory size by running the following command Lokesh> Loop: create a.b...
Creating mutliple versions of the same file is actually the most efficient, least space occupying method to store a file. It just adds a files-id and a little overhead to an array, based of the same name. Next time, if you really want to explode a directory in a hurry make a loop with fresh, It if you like creating work for the system, create them in reverse or random order. long, filenames: $loop: $x = x=f$cvtime("",,"hundredth") + f$cvtime("",,"second") $create 'x-get-creative-here.and-here $if not-done then goto loop
Lokesh>
bradford> set file/truncate DSA2:[000000]TESTLJ.DIR
NO, IMHO it is NOT a good idea to truncate Directory files. Use DFU, as Ian points out. Its great. best thing since sliced bread and all. Check out it's other functions (fragmentation report, quick file searched). It will soon ship with VMS.
Willem> _might_ mean that when a calculated slot within the directory-file is already occupied, it's very well possible that the new slot will be at the end of the directroy file
Close, but no cigar. Directory records are in strict sequential order. Use DUMP/RECO or DUMP/DIRECTORY to visualize. There is NO hashing on disk, but the XQP builds a little in memory table based on the first few characters (so don't pre-pend fluff!). There is indeed a notion of name ranges for a BLOCK in a directory, trying to fit a new name in a logical spot. If that block is full, the whole directory will be re-copied opening up a block. This USED to be done with single block IOs as an easy way to garantuee recoverability.! (pre 7.2).
Ian> Note that directories should be kept below 127 blocks in size as there is a severe performance degradation above this size.
This is still agood guideline, but it never really was a hard and fast rule. It was there because RMS had a 127 block max size for (repeated) WILDCARD lookup ( mail$*.mai). Individual file lookup, without wildcard were/are done by the XQP with a modified binary search algoritme. RMS can now (7.2+?) deal with larger directories, making the performance 'knee' much softer. But exsessive directory sizes still hurt some.
