device full (insufficient space for allocation)”

[adarsh_4]

i have a disk which has got 56247296 of free blocks out of 142264000. we have a folder on this disk where we do our backup.

recently i get this error "device full (insufficient space for allocation)” even thought there is space on the disk. what can we do to increse the size of this directory.

[Robert Gezelter]

adharsh,

Some context would be useful.

How large was the file being allocated? A SHOW DEVICE/FULL of the device in question would also be useful.

- Bob Gezelter, http://www.rlgsc.com

[Jeremy Begg]

Adarsh,

What Bob is asking you for will confirm the disk capacity (i.e. the total number of blocks on the disk and the number of free blocks on the disk). It's useful information.

When you say "a folder on this disk where we do our backup", what kind of backup? Do you mean the VMS BACKUP command, or some other program? (Perhaps you mean backup from a remote system?)

Note that VMS doesn't place limits on the number or size of files which can be stored in a particular directory. However it is possible to have a disk quota for each user, ie. a limit to the number of disk blocks in use by each user. Perhaps you have a quota in place for the user who owns the backup files. It's easy to check:

$ MCR DISKQUOTA
DISKQ> USE device:
DISKQ> SHOW *
UIC Usage Permanent Quota Overdraft Limit
%DISKQ-E-EXAMINERR, cannot examine quota file entry
%SYSTEM-E-QFNOTACT, disk quotas not enabled on this volume
DISKQ> EXIT
$

Substitute your disk device name for 'device' in the above commands. The error shown is what you see if there are no quotas defined for the disk.

Regards,
Jeremy Begg

[Hoff]

Here's the generic answer for a disk device that's full:

http://labs.hoffmanlabs.com/node/939

but for this case, I suspect you have some combination of a severely fragmented disk and/or gigantic directories ("folders" in play here.

The latter case means using subdirectories or otherwise reducing the numbers of files in these directories, and using disk defragmentation or BACKUP to clean up the disk structures.

That, or (given the unfortunate lack of context around the failure) you're simply trying to load more onto the "backup" disk than it has room for. If so, see the link above, and start looking at either bigger or more disks, or both.

[Jon Pinkley]

adarsh,

See this thread about DFU

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1296001

My post made on Dec 12, 2008 07:56:49 GMT has a potential solution to getting some contiguous free space on a disk with highly fragmented free space without having to resort to a complete image backup/restore.

Jon

[Volker Halle]

adarsh,

please show us the exact command used and the exact error message. Use cut & paste to provide this information literally.

Volker.

[adarsh_4]

Mr Bob, here is the sh dev d.

the total blocks is 142264000 and the free blocks as of now is 39939648

the disk quota commands gave this result.

ADARSH>>mc diskquota
DISKQ>use dka200
DISKQ>sh *
UIC Usage Permanent Quota Overdraft Limit
%DISKQ-E-EXAMINERR, cannot examine quota file entry
%SYSTEM-E-QFNOTACT, disk quotas not enabled on this volume


the command we use to do backup is $rmu/backup/online fscfinance:[FINANCE_V2.DATA]FINANCE.RDB - fscback:[db_backup]FINANCE.rbf


the directory is db_backup on fscback (dka200:)

[Hein van den Heuvel]

The assumption has to be that the error is a correct indication of what is going on.

This is not the first time a backup is being made right?

Based on past backups, how big do you expect the RDB backup file to become? How large are the datafiles?

Your first reply indicated 28GB free.
The reply just now indicates 20GB, a 10% swing in device space usage.
So it appears that the device usage is in flux.
Might you have attempted the backup when the free space was at a (temporary) low?

notes:
1) Forget about the directory, for purposes of free space only the device counts, not the directory.

2) Be sure to also issue the command : $SHOW DEVIVE fscback:
... in the context of the process where the backup was tried. Just in case that logical does NOT point where you think it does

3) It is easy and not too much overhead to enable quotas, but I doubt you'll learn more from that.

4) Use DFU to find the big file on the target device:
$ DFU SEARC /SIZE=MINI=5000000 fscback:
If you don;t have DFU, then get it. No OpenVMS system should be without.
http://www.digiater.nl/dfu

Good luck!
Hein

[Volker Halle]

adarsh,

and the exact error message is ???

Volker.

[David Jones_21]

Which OpenVMS version are using and is it a clustered machine? We used to have a problem with the file system being unable to allocate on a volume that had lots of free space. A reboot of the afflicted node would fix the problem. I haven't seen the problem since upgrading to 8.3.

Try a set volume/rebuild=force on the on the disk.

[Hoff]

This may well be the wrong disk here; the disk being discussed might not be the disk tossing the error being reported.

Start looking at the process's local login disk, and at any other disks with Oracle Rdb files (database or journal or otherwise) as Rdb can toss up these errors.

In particular, the command here is using the Oracle RMU, and that can write to and allocate space on rather more than just the target disk device.

Which disks Oracle Rdb writes its data to depends on how the local site has configured Oracle Rdb; that varies widely.

One of the classic spots for these sorts of errors is the RDMS$RUJ directory, if the local site using a more distributed organization for Oracle Rdb. That directory can require quota and adequate storage and contiguous storage.

Better yet, look at the fragmentation and the percentage full on all of the local disks, and maintain sufficiently large freespace and sufficiently low fragmentation on each.

nb: This HP OpenVMS and Oracle Rdb configuration should undergo a review for the correctness of the archival processing and for general HP OpenVMS system and Oracle Rdb database operations.

[Peter Zeiszler]

Sometimes when a disk errors on its allocation you can see it with "anal/disk diskname". We get that sometimes after a reboot where it thinks there is no space but its just erroring on its allocation. (usually if the system has open files when its rebooted)

[Steve Reece_3]

It's worth remembering that although VMS doesn't implicitly put any limits on the files in a directory, there can be issues when directory files get large. I've seen systems where directories become corrupt when they grow large, meaning that the files within them are not accessible.

Steve

[adarsh_4]

the error i get in the log file is shown below

%RMU-F-WRITEERR, error writing FSCBACK:[DB_BACKUP]ENGINEERING.RBF;
-RMS-F-FUL, device full (insufficient space for allocation)
%RMU-F-FATALERR, fatal error on BACKUP
%RMU-F-FTL_BCK, Fatal error for BACKUP operation at 18-NOV-2009 00:42:46.69

[Hoff]

The error indicates that copying too much data was attempted, or that the target disk is too fragmented for the RMU attempt; that the RBF file was too big, or the disk too fragmented, or other such.

oracle Rdb can also occasionally generate these errors when your login device (and usually the [RDMS$RUJ] directory and the database journal files that get written there) or when another device that is associated with the Rdb database is full or fragmented, as well.

Which usually means that some cleaning up of some or all of the contents of the disk(s) involved will be required; of freeing space on the disk. Or replacing the disk with a disk with more free space; with an empty disk or with a bigger disk. Or copying over less stuff to the disk.

Given we're looped back to what looks to be the original problem statement with no particular progress, please contact your support organization or preferred formal escalation channel for assistance here; to have a look at this case.

[John McL · Accepted solution]

"$ HELP/MESSAGE insufficient space for allocation" gives the response...
---------
Facility: RMS, OpenVMS Record Management Services

Explanation: A $CREATE, $EXTEND, or $PUT operation for a file failed because there is not enough space on the volume or there is
not enough contiguous space (in the case of a request for contiguous space).

User Action: Delete or purge as many files as possible to provide usable space on the volume, or request the system operator to do so. If the volume is private and files cannot be deleted, obtain a new volume.
------------

Do you have a lot of fragmentation on that disk? If so, then defrag it and try again.

P.S. I like the last sentence in that help message.

[Jon Pinkley]

adarsh,

Everything you have shown us is consistent with the FSCBACK: device running out of space.

What evidence do you have that it did not fill up, or there was insufficient space for the .RBF file to be extended?

The latest instance is when ENGINEERING.RBF was being written, although you told us before if was FINANCE.DBF that was being written. You provide us with nearly no information, yet you expect us to be able to tell you why you are getting the error.

How large do these RBF jounal files get?

The next time you run the backup, while it is running, start SDA (Analyze/system), set the process to the process running RMU (SDA> Set proc/id=<8 hex digit PID of process>, then show what channels are active for the process.

example: assume process id is 2BAD4DEC

$ set proc/priv=all
$ analyze/system
SDA> set process/index=2bad4dec ! this works
SDA> set output/noheader/noindex/single sys$login:chan.txt
SDA> sho proc/chan
SDA> exit
$ show device d/mounted

Then look at the chan.txt file and see what devices are being used.

Repeat show device d/mounted several times at 5 minute intervals.

If the RMU backup is being done by a batch job, you may want to submit another batch job that runs at the same time that monitors the disk space.

Even something as simple as:

$ ver='f$verify(1)'
$ set noon
$ set prefix "(!8%T) "
$ set output_rate=00:00:10
$_top:
$ show device d/mount
$ wait 00:01:00 ! wait a minute
$ goto _top

you can just toss a delete/entry=xxxx at the batch job when done.

At least you will then have a record with 1 minute granularity of the free blocks while your backup is running.

It's been over 15 years since I used RMU, so this may not be accurate. I don't think that RBF files have to be contiguous or are limited to a single file header. Also, unless the FSCBACK:[DB_BACKUP] has many more files than I would expect it to, I think it is unlikely that the FSCBACK:[000000]DB_BACKUP.DIR file can't be extended. So I think that Hein's guess is the most likely, i.e. the disk really is getting filled up.

Did you follow the advice about analyze disk/repair or set volume/rebuild=force? It is possible that the free space being reported is not correct, and an analyze/disk/repair will correct that.

Jon

[adarsh_4]

thank you mr Pinky, i followed what u said and manage to fix the problem. thanks once again and thanks to all of you.

[adarsh_4]

sorry its Mr Pinkley