Operating System - OpenVMS
1748256 Members
4058 Online
108760 Solutions
New Discussion юеВ

Re: File attributes: Allocation: 5000 - VMS 7.3-2

 
SOLVED
Go to solution
Jorge Cocomess
Super Advisor

File attributes: Allocation: 5000 - VMS 7.3-2

Hi,

Does anyone here can tell me what's the meaning of the File Attributes Allocation: 5000??

Here's are the info when I typed DIR/FULL on a directory:

File attributes: Allocation: 5000, Extend: 0, Global buffer count: 0
No default version limit, Contiguous, Directory file

Total of 1 file, 93/5000 blocks.


Am I capped at 5000 VMS blocks or something like that?? If yes, how can I change this to be unlimited??

Thank you in advance.

Jorge
18 REPLIES 18
Hein van den Heuvel
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

Jorge,

It just means that the particular fiel CURRENTLY has 5000 block allocateed to it.

You can 'see' exactly which physical blocks it have using DUMP/HEAD/BLOCK=COUNT=0 for the file.

Is does not mean the file can not grow if and when it needs to.

The growth with constraing first by
- disk quota (if enabled)
- free blocks on the disk (in general)
- largest free contiguous chunk on the disk in this particular case where the file is currently contiguous and must stay that way, because it is a directory file with special constraint.

Why are you asking?
Just for clarification?
Do you think there is a problem?
An error in an application?

hth,
Hein.

Robert Gezelter
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

Jorge,

The file presently has 5000 blocks allocated. In addition to the questions that Hein has asked previously, I would add the question of how was the file created? If there is an FDL file used in the file creation process, then it is likely that there is an explicit allocation in that file (and also a request to make the file CONTIGUOUS).

- Bob Gezelter, http://www.rlgsc.com
Hein van den Heuvel
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

Bob, fwiw... It's a directory!
File attributes: ... Directory file

Surely no FDL
It probably simply had 10,000+ files in it at some point in time and now there are only a few hundred left.

Hein.
[0 points for this please]
Robert Gezelter
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

Hein,

Mea culpa! I was tired and missed the "Directory" file when I read his post.

In that case, while it would seem the allocation was driven by growth, however, there remain two possibilities:

- the use of the CREATE/DIRECTORY/ALLOCATION=nnn command (beginning with the last few releases).

- the underlying granularity of the volume

Perhaps Jorge can shed some light on how this directory was created and used?

- Bob Gezelter, http://www.rlgsc.com
Jorge Cocomess
Super Advisor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

Hi,

The directory was mainly for writing application logs into this directory, whic mostly .txt file. Every so often, we have to clear out the directory after couple of weeks or about 1500 or so files, because the application was not able to write to this directory. This directory does not have disk space constraint or any constraints as I know of. Below, is the directory characteristic "DIR/FULL" command.

Directory DISK56:[000000]

DDR_STATS.DIR;1 File ID: (666,3,0)
Size: 93/5000 Owner: [SYSTEM]
Created: 3-NOV-2005 12:32:04.34
Revised: 21-JAN-2008 17:07:56.83 (47812)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 5000, Extend: 0, Global buffer count: 0
No default version limit, Contiguous, Directory file
Record format: Variable length, maximum 512 bytes, longest 512 bytes
Record attributes: No carriage control, Non-spanned
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RWED, World:RWED
Access Cntrl List: None
Client attributes: None

Total of 1 file, 93/5000 blocks.

Karl Rohwedder
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

Jorge,

if the applicatin fails to write to the directory, this may be caused by:
- the disk is full
- diskquota enabled and no more left
- the index file of the disk is full and no new file headers can be created

The latter may be cured by initializing a new disk and doing a BACKUP/IMAGE/NOINIT to it.

Btw, the DFU utility is able to compress/truncate directories.

regards Kalle
Hein van den Heuvel
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2


>> Every so often, we have to clear out the directory after couple of weeks or about 1500 or so files, because the application was not able to write to this directory.

What does 'not able to write mean'?
Privillege violation?
Allocation failure?
Not quick enough?

The most likely reason for trouble here is really fragmented free space on the drive.
Check with DFU REPORT or DFO.

And uh... yo really rally want to maintain your directories irrespective of this problems. Above 1000 blocks or so, the cost of random inserts and deletes becomes significant.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting


Robert Gezelter
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

Jorge,

I must concur with Hein's most recent comment. It is impressive how sparse a directory can become with an ongoing chain of creations and deletions. When I encounter problems with this at clients, it is often mail directories or directories that are used as transient storage locations.

Unless you are particularly short of disk space, I would be inclined to leave the file as it is. Directories must be contiguous, and if there is a shortage of contiguous space on that disk, one can later regret shortening the directory.

If the directory appears to be full, there are several ways to address the problem.

Certainly, as Karl has mentioned, DFU can reorganize a directory. If you are not familiar with DFU, or it is not installed, there is a simple solution that requires nothing more than straightforward DCL.

An example. Directory [AAA] shows that it is almost completely full, and it is reported that some attempts to add files to the directory are failing. Without DFU, the following will reorganize the directory [admitttedly it does require some space]:

$ CREATE/DIRECTORY [BBB]
$ RENAME [AAA]*.*;* [BBB]*.*;*
$ RENAME [BBB]*.*;* [AAA]*.*;*
$ DELETE [000000]BBB.DIR;*

If I need to do this repeatedly, I keep around the scratch directory for future use. DFU would be nicer, but in some situations, it is not available.

- Bob Gezelter, http://www.rlgsc.com
Willem Grooters
Honored Contributor

Re: File attributes: Allocation: 5000 - VMS 7.3-2

In addition to both Bob and Hein:

Directory files need contigous space. If a directory is full, it will be expanded (by the disk's clustersize?) and stored on a location that can hold the whole file. If there is no=t enough contigoeus space on disk, you'll get an error and the file you added will either be 'invisible' by normal means (the directory file is not chnaged so the file won't show up) or it may have a size of 0. I've seen both.

Using that amount of files in one directory is (used to be?) a not-so-good idea.

Though you have 93 blocks actually used, 5000 blocks are allocated. It could mean several things, but it all boils down the the disk's clustersize. If it has been set to 5000, creation of the directory file will allocate 5000. Each extension will add 5000 bytes. If your clustersize is 2500, it might have been the file was filled up and a newly added file would cause extension - that's where 5000 (2*2500) comnes from.

Keep in mind that restoring files from backup, the original allocation will be used, rounding up to local clustersize:
Willem Grooters
OpenVMS Developer & System Manager