- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: -RMS-F-FUL, device full (insufficient space fo...
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
The article you are trying to access is permanently deleted.
- 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
тАО06-02-2008 07:58 AM
тАО06-02-2008 07:58 AM
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 08:04 AM
тАО06-02-2008 08:04 AM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 08:15 AM
тАО06-02-2008 08:15 AM
SolutionYou 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 08:15 AM
тАО06-02-2008 08:15 AM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 10:52 AM
тАО06-02-2008 10:52 AM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 12:10 PM
тАО06-02-2008 12:10 PM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 12:41 PM
тАО06-02-2008 12:41 PM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 01:33 PM
тАО06-02-2008 01:33 PM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 05:12 PM
тАО06-02-2008 05:12 PM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-02-2008 10:29 PM
тАО06-02-2008 10:29 PM
Re: -RMS-F-FUL, device full (insufficient space for allocation)
http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1212473276643+28353475&threadId=1141655
Wim