- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Allocation Error
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2008 12:17 PM
тАО09-04-2008 12:17 PM
Any suggestions? Thanks as always for your assistance. Let me know if you need more info.
%RENAME-E-OPENOUT, error opening DB$ROOT:[TRANS]DB_CX_DEL_DBO_TRANS__4SEP200814130351.DAT; as output
-RMS-E-ENT, ACP enter function failed
-SYSTEM-W-DIRALLOC, allocation failure on directory file
%SYSTEM-F-ABORT, abort
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2008 12:30 PM
тАО09-04-2008 12:30 PM
SolutionAh, cute one.
This means there is not enough CONTIGUOUS free space on the drive to re-allocate that directory 'one size bigger'
Workarounds
1) delete or rename away, some files from teh problem directory.
2) delete some large files which hopefully occupied contiguus space
3) compress the directory (DFU)
3) compress the directory slowly:
$SET DEF DB$ROOT:[000000]
$RENAM TRANS.DIR OLD.DIR
$CREATE/DIR [.TRANS] /prot... /own...
$RENAM [.OLD]*.*;* [.TRANS]
Be sure to download and check out DFU: http://www.digiater.nl/dfu
DFU REPORT DB$ROOT:
Soem privs to read bitmap.sys and a keen eye for details is all you need:
"Largest free extent (blocks)...."
The reason it may have worked before is that directories are ordered, but the blocks can be sparsely filled.
A delete can leave room to be filled by a futreu file in the same name range.
However, when a file name needs to be inserted where the block is full, and all the block in the directory file are used, then the systems needs to make space by allocating an entire fresh directory .. CONTIGUOUSLY... which failed.
Enjoy,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2008 12:34 PM
тАО09-04-2008 12:34 PM
Re: Allocation Error
To amplify somewhat Hein's correct comments. Directories are required to be contiguous. Thus, if the amount of available contiguous space on the volume changes, the ability of the directory to expand can change.
As earlier noted, directories can become quite sparsely populated and substantially compressed. Either of the solutions that Hein mentions:
- using DFU
- using RENAME and a scratch directory (In such situations, I prefer to use a scratch directory to retain the original contiguous directory for the somewhat inevitable expansion).
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2008 12:45 PM
тАО09-04-2008 12:45 PM
Re: Allocation Error
Btw...
Any such rename as I an bob suggested can get rather slow for large directories.
This is because blocks being emptied will be expunged as it proceeds.
Savvy folks for use $SET FILE/ENTER to populated a compressed parallel directory, rename and/or delete the old, and rename the new to the real name. See example below
But savvy folks possibly would not have asked this question to begin with!
$ set def [.tmp]
$ cre /dir [.a]
$ copy nl: [.a]x.1
$ copy nl: [.a]x.2
$ copy nl: [.a]x.3
$ copy nl: [.a]x.3
$ copy nl: [.a]x.1
$ dir/file [.a]
Directory [HEIN.TMP.A]
X.1;2 (129739,55,0)
X.1;1 (129731,47,0)
X.2;1 (129733,27,0)
X.3;2 (129738,63,0)
X.3;1 (129734,18,0)
Total of 5 files.$ cre /dir [.b]
$ cre /dir [.b]
$ set file/enter=[.b] [.a]*.*;*
$ set prot a.dir
$ set file/nodir a.dir
$ delete a.dir.
$ renam b.dir a
$ dir/file [.a]
Directory [HEIN.TMP.A]
X.1;2 (129739,55,0)
X.1;1 (129731,47,0)
X.2;1 (129733,27,0)
X.3;2 (129738,63,0)
X.3;1 (129734,18,0)
Total of 5 files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-04-2008 12:47 PM
тАО09-04-2008 12:47 PM
Re: Allocation Error
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-05-2008 05:45 AM
тАО09-05-2008 05:45 AM
Re: Allocation Error
It leaves the backlink pointer in the file header pointing to the wrong directory (and when the directory is deleted, a non-existent directory).
The price is that lib$fid_to_name will not be able to return a valid path to the file.
$ dfu directory/compress does not suffer from that problem.
Attached is a zip file with a command procedure that demonstrates the problem, and a log file of its use.
Another thing to note is that the fid display returned by DCL's f$file_attributes(file,"FID") and the output of directory/file are the same. Also
the output returned by lib$fid_to_name and show device/file are the same. But the f$file_attributes(file,"FID") format is different than lib$fid_to_filename. Dump/header agrees with f$file_attibutes.
Excerpt from log file after the set file/enter, delete a.dir
$ open/read tmp [.A]X.1
$ ppf tmp
$ show symbol *_file*name
FID_FILE_NAME = "DISK$USER1:[436157,29,0]X.1;1"
ORG_FILE_NAME = "ROOT$USERS:[JON.SCRATCH.A]X.1;1"
PHY_FILE_NAME = "DSA1200:[USERS.][JON.SCRATCH.A]X.1;1"
$ show dev/file sys$disk
Files accessed on device DSA1200: on 5-SEP-2008 08:20:34.97
Process name PID File name
00000000 [000000]INDEXF.SYS;1
00000000 [000000]QUOTA.SYS;1
JON 202D3683 [436157,29,0]X.1;1
$ close tmp
$ exit
$ dir/file [.a]
Directory ROOT$USERS:[JON.SCRATCH.A]
X.1;1 (436187,33,0)
Total of 1 file.
$ exit
$! note difference in FID displayed by directory and show device/files (436187,33,0) vs. [436157,29,0]
$! which is correct? (it appears directory output is)
$ dump/wid=80/rec a.dir ! let's see what is in the directory
Dump of file ROOT$USERS:[JON.SCRATCH]A.DIR;1 on 5-SEP-2008 08:21:32.14
File ID (441691,13,0) End of file block 1 / Allocated 8
Record number 1 (00000001), 16 (0010) bytes, RFA(0001,0000,0000)
06000021 A7DB0001 00312E58 03007FFF ....X.1...├Г ├В┬з!... 000000
$ fid$w_num=%xA7DB
$ fid$w_seq=%x0021
$ fid$b_rvn=%x00
$ fid$b_nmx=%x06
$ fid_num=fid$b_nmx*%x10000+fid$w_num
$ fid=f$file_attributes("[.a]x.1","FID")
$ sho sym fid*
FID = "(436187,33,0)"
FID$B_NMX = 6 Hex = 00000006 Octal = 00000000006
FID$B_RVN = 0 Hex = 00000000 Octal = 00000000000
FID$W_NUM = 42971 Hex = 0000A7DB Octal = 00000123733
FID$W_SEQ = 33 Hex = 00000021 Octal = 00000000041
FID_NUM = 436187 Hex = 0006A7DB Octal = 00001523733
$
Looks like a bug in what lib$fid_to_name displays when path cannot be determined from backlinks.
The attached .zip file was created using the "-l" switch on VMS so it would create DOS compatible text files on windows. To unzip on VMS, set your default directory to where you want the files created, then use the command:
$ unzip "-aa" itrc_dir_compress
if you do not use "-a" or "-aa", every line will have a
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-05-2008 08:30 AM
тАО09-05-2008 08:30 AM
Re: Allocation Error
$ RENAME [.A]*.*;* [.A]*.*;*
but of course that has the side-effect of resetting each file's modification date.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-05-2008 08:34 AM
тАО09-05-2008 08:34 AM
Re: Allocation Error
I actually tried that, and it didn't do anything. If you rename to a different name or directory, it does fix the backlink, but there must be an optimization that makes the rename to the same directory/name a no op.
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-05-2008 09:09 AM
тАО09-05-2008 09:09 AM
Re: Allocation Error
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-05-2008 10:06 AM
тАО09-05-2008 10:06 AM
Re: Allocation Error
Output from dump/header/block=(count:0) shows this:
Dump of file ROOT$USERS:[JON.SCRATCH.A]X.1;1 on 5-SEP-2008 13:57:26.95
File ID (436187,33,0) End of file block 0 / Allocated 0
,,,
File identification: (436187,33,0)
Extension file identification: (0,0,0)
...
Back link file identification: (436157,29,0)
...
Identification area
File name: X.1;1
So that's where the [436157,29,0]X.1;1 comes from. It isn't FID of the file, but of the directory the file was originally created in.
Sorry for the confusion.
Jon