topic Re: Allocation Error in Operating System - OpenVMS

Allocation Error

odwillia — Thu, 04 Sep 2008 19:17:33 GMT

We received this error in the afternoon and the same process completed fine earlier today.
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

Re: Allocation Error

Hein van den Heuvel — Thu, 04 Sep 2008 19:30:10 GMT

Ah, 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.

Re: Allocation Error

Robert Gezelter — Thu, 04 Sep 2008 19:34:03 GMT

odwilla,

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

Re: Allocation Error

Hein van den Heuvel — Thu, 04 Sep 2008 19:45:14 GMT

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.

Re: Allocation Error

odwillia — Thu, 04 Sep 2008 19:47:33 GMT

Quite Savy indeed. Thanks for the quick responses.

Re: Allocation Error

Jon Pinkley — Fri, 05 Sep 2008 12:45:51 GMT

As with many shortcuts, there is a price to pay for using the set file/enter shortcut.

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 appended to the end.

Jon

Re: Allocation Error

Jess Goodman — Fri, 05 Sep 2008 15:30:22 GMT

You can fix the back-link problem on all the files in the directory by a simple:

$ RENAME [.A]*.*;* [.A]*.*;*

but of course that has the side-effect of resetting each file's modification date.

Re: Allocation Error

Jon Pinkley — Fri, 05 Sep 2008 15:34:31 GMT

Jess,

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

Re: Allocation Error

Jon Pinkley — Fri, 05 Sep 2008 16:09:43 GMT

For future reference, the testing I did was on Alpha VMS 7.3-2.

Re: Allocation Error

Jon Pinkley — Fri, 05 Sep 2008 17:06:38 GMT

My babbling about show dev/file showing the incorrect FID was bogus. It is displaying the DID'ed directory name, in this case the FID specified as the Back link identification, which is no longer valid.

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

Re: Allocation Error

Jon Pinkley — Fri, 05 Sep 2008 20:13:12 GMT

After more testing, it appears that rename does not fix the backlink, even when renaming to a different name or different directory. My guess is that this is expected behavior, since it is not consisdered the primary link. I.e. the directory pointed to by the backlink does not have an entry with the filename and fileid of the file. So the backlink is not updated.

Analyze disk/repair treats the file as a lost file and puts an entry in [syslost], which doesn't seem to be the correct thing to do, but to avoid that would require that every directory on the disk be searched for an entry with the file id of the file in it.

There doesn't seem to be an easy way to fix the problem using standard utilities. What does work: analyze/disk/repair; set file /remove from target directory, rename from [syslost] to target directory (this updates the backlink because the [syslost] is now the primary entry.

Bottom line: this is a shortcut to avoid if correct backlinks are important to you.

On the other hand, if you are trying to hide files and wnat them to be hard to find, it may be useful.

Jon

Re: Allocation Error

Hein van den Heuvel — Sat, 06 Sep 2008 14:12:30 GMT

Odwillia,

I'm sure you heard more than enough.

There are more, and older discussion on this:
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1165943

Just get more space, or use DFU or use an old 'comdir' or such if you can find it.

Jon,

Good catch on the potential backlink issue.
That changes savvy to silly.

The most likely place where folks would actually suffer from a broken backlink is probably
$SHOW ENTRY/FULL
It use the FID -> Name and would fail.
It might report a file as:
_$10$MDA0:[14,4,0]X.COM;1

While this IS a valid DID abbreviated file spec, it will fail because that DID no longer is there.

http://h71000.www7.hp.com/doc/731FINAL/4506/4506pro_019.html#index_x_1071

The FID abbreviated name does not provide an alternative as it (un-necesarilly so?!) requires the correct directory even though the FID is unique already. Oddly it does not require a valid leading name character such as the doc implies:

$ dir/nohead/notrail/file/wid=file=40 _$10$MDA0:[a.test]y~[13,3,0].com
_$10$MDA0:[A.TEST]X[13,3,0].COM;1 (13,3,0)
$ dir/nohead/notrail/file/wid=file=40 _$10$MDA0:[a]y~[13,3,0].com
%DIRECT-W-NOFILES, no files found

Anyway... if someone wanted to use this savvy/silly shortcut instead of a proper tool, then the better way to so is:

$create/dir device:[temp]
$set file/enter=[temp] device:[data]*.*;*
$set file/nodir device:[000000]temp.dir
$copy/over device:[000000]temp.dir data.dir !!!
$delete device:[000000]temp.dir;

That is quick and preserves the FID for data.dir.

Yuck...

:-)

Hein.