-RMS-F-FUL, device full (insufficient space for allocation)

[Chuck Sopher]

I was attempting to do a COPY/CONTIG/LOG of a file to a new shadow set that had no files, other than the 9 sys files the 000000.dir and the directory I was trying to copy into. I received the error, "-RMS-F-FUL, device full (insufficient space for allocation)" until I removed the "/CONTIG" qualifier. The siz of the file was 77824000 blocks. Is there a limit on the size of the file copy/contig can handle or could it be due to bad blocking or is there some other more obvious answer? Thanks.

[labadie_1]

Hello

Yes there is a limit, but it is about the size of a single file, and you are very far from it.

You should install DFU, which will tell you ho much contiguous space you have on any disk.

http://www.digiater.nl/dfu.html

$ mc dfu report dsa1:

for example, will say mong many other things, the biggest contiguous chunk.

[Hoff · Accepted solution]

Ok, so new (blank) disk, freshly initialized using (mostly) defaults, and a COPY /CONTIG of a file of somewhere between just under half the total disk size and the disk size fails? Correct?

You probably need to reinitialize and move the index file from its default position in the middle of the disk to the front (lowest LBN) or the back (highest LBNs) of the disk.

See HELP INITIALIZE /INDEX=kw for details.

Disk initializations will also inherently insert alternate home blocks (on recent releases -- might want to remember to include platform and version -- all home blocks are alternate home blocks) into the volume structure, and these, too, can block large contiguous allocations. This is somewhat controllable with the homeblock placement knob.

HELP INITIALIZE /HOMEBLOCK=hw for details.

These two are usually combined.

Contiguous files this big tend to point to a need for or the use of your own file system of some sort, or other such activities; in most cases, there is seldom much benefit from going contiguous in this size range otherwise. Barring cases where the host software itself can't deal with the fragmentation, that is.

[Robert Gezelter]

Chuck,

How large is the Shadow Set? How was the volume initialized?

Per chance, was the file larger than half the size of the shadow set and the index file was placed in the middle of the volume?

The DUMP/HEADER command can be used to look at where the INDEX file [000000]INDEXF.SYS is actually located. The actual sizes of the volume can be displayed using SHOW device/FULL.

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

[Chuck Sopher]

Robert,

The size of the Shadow Set is 142,255,575 blocks. It was initialized with just the standard init command (no special qualifiers). The file size was 77,824,000 blocks (a little more than half the size of the shadow set). Would moving the index file
have negative impact on disk performance? I have to move a different file to a different new Shadow Set with a patentially similar situation? Thanks a lot!

-Chuck

[Jim_McKinney]

> Would moving the index file have negative impact on disk performance?

Unlikely - is this the only file that will reside on the disk? If so, you won't be visiting that index very often. If this is the case then it really doesn't matter where the indexf is other than it need be located somewhere where it won't split your contiguous space such that you can't make your file contiguous. The reason for the indexf being placed in the middle of disks by default is based upon a theory that suggests that as a disk fills with lots of files your seeks will become spread across the disk from center to rim - and if the indexf were in the middle, then on average, you've likely shortened the seek time to reach it.

[Hoff]

Going to contiguous files or to disk block positioning or to disk geometry operations can tend to indicate forms of premature optimizations.

This comment in the absence of additional background or information around specific reasons for the use of these choices.

There can certainly be cases where an application needs to run at the spiral transfer rate of the storage controllers and storage devices, though an overlapped sequence of moderate-sized I/O transfers does very nicely. Or you can let, for instance, OpenVMS paging I/O load the data. And the best I/O is no I/O; running from within memory.

Conversely, big files can stink for BACKUP-like tasks.

Yes, you need either use a non-contiguous transfer for the existing disk, or you need re-initialize the disk.

The ODS-2 and ODS-5 indexed file default placement (in the middle of the expanse of disk blocks) and the alternate home blocks will both conspire to prevent gonzo-scale contiguous allocations.

[John Gillings]

Chuck,

> negative impact on disk performance?

Difficult to say without knowing the use for your file and the technology of the storage.

If the disks are physical spindles and your file is accessed strictly, sequential, multi buffered, continuously at near to the theoretical transfer limit of the drives, then you MAY be able to measure a performance difference between contiguous and non-contiguous placement.

If it's random access or multiple users, then there's a reasonable argument to say that non-contiguous placement may give BETTER performance (since the place you leave the heads after a read is somewhere you know will definitely NOT be accessed next).

If your storage is EVA-like, then "contiguous" really doesn't mean much anyway. The storage is scattered around the place by the controller.

In modern, multi user, multi threaded, complex environments, with many layers of caching and optimization between an I/O operation and the physical storage, contiguity is mostly just a warm fuzzy for people who like the idea of order and neatness. Except in pathological cases, either in extreme performance requirements, or extreme fragmentation, any differences in performance are barely measureable.

The downside of requiring contiguity is you create error conditions which are arguably unnecessary (such as the one you're reporting in this thread), adding to the complexity of managing your data.

If you're worried about fragmentation, INITIALIZE your disk with the largest possible cluster size, and leave the rest to OpenVMS to deal with.

[Jon Pinkley]

RE:"Is there a limit on the size of the file copy/contig can handle?"

Yes, it is 0.5TB or 2^30 (1073741824 decimal) blocks. That's the largest size that can be mapped by a single (format 3) retrieval pointer. Ref: VMS File System Internals, Kirby McCoy Sec 2.3.3.3.4 pgs 36-37.

If there is sufficient contiguous space and you attempt to create a contiguous file larger than 1073741824 blocks, you will get the following error:

OT$ copy nla0: $1$dga600:[000000]big.file /allo=1073741825/contig
%COPY-E-OPENOUT, error opening $1$DGA600:[000000]BIG.FILE; as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-E-UNSUPPORTED, unsupported operation or function
%COPY-W-NOTCOPIED, NLA0:[].; not copied
OT$

That's a different message that you saw when there isn't contiguous space, although I will not argue that either error message is very helpful if you aren't familiar with the underlying cause.

OT$ copy nla0: $1$dga600:[000000]big.file /allo=1073741824/contig ! this is the largest that works.
OT$

You can have a file that is larger than 2^30 blocks that is contiguously allocated, i.e. for every VBN in the file, (LBN-VBN) is a constant value, but for a file to be created /contiguous requires that all blocks fit into a single retrieval pointer.

Andy G was discussing this very thing with a customer at the Partners roundhouse on May 20th at the bootcamp in Nashua.

But as others have stated, the cause in your case was the lack of contiguous space due to the default placement of the indexf.sys file near the middle of the volume.

Jon

[Wim Van den Wyngaert]

You can follow the space allocation with defrag/int=decw using the report / volume option. You can see where it allocates the space on disk. I once did it.

http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1212473276643+28353475&threadId=1141655

Wim