- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Reclaim disk space
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-08-2005 07:45 PM
тАО09-08-2005 07:45 PM
Re: Reclaim disk space
Phil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2005 11:43 PM
тАО09-08-2005 11:43 PM
Re: Reclaim disk space
Phil wrote:
"Would this happen if the rms file has global buffers (unlikely if it's an archive, but you never know)"
Hmmm, this is sooo wrong on sooo many levels. It expresses and perpetuates an undeserved fear of the unknown: the rms global buffers.
1) "Would what happen?"
1A) Accidental deletes for file with global buffers? Sure!
1B) Free space not becoming visible after a delete of a file with global buffers? Possibly, but not more or less so because of those global buffers.
Those matters are utterly unrelated. Global buffers have NOTHING what so ever to do with file deletes.
They are NOT mapped file sections, but they are global buffers used to buffer IO to an from teh file into. They could readily continute to exist for a deleted file (allthough that would be pointless and it would represent a bug in rms)
2) While I agree you will not see global buffers on an archived file, why would you not want global buffers on an a file which receives archive records? Those could receive records from mutliple concurrent processes. Those could have frequent queries that can benefit from 'warmed up' buffers.
Anyway, it is a moot point as per above.
cheers,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-09-2005 01:28 AM
тАО09-09-2005 01:28 AM
Re: Reclaim disk space
I would rate Peter's comments about "are you sure that nobody else grabbed the space" far more seriously than I would consider a reboot.
Reboot is unlikely to clear anything. I might, in some cases, consider dismounting and remounting the volume, but certainly not as an early course of action.
You said that you ran an ANALYZE/DISK/REPAIR. Check directory [SYSLOST] for the file. If the errant user removed the directory entry for the file, but did not actually issue a DELETE on the file, it may be considered a lost file. ANALYZE/DISK/REPAIR should have reported that it found a "lost file", but the message may have scrolled off of the screen.
If the file is in [SYSLOST] on the affected disk, then it can be put back in its correct location using the RENAME command.
More information would be extremely helpful. I hope that the above is helpful.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-09-2005 01:36 AM
тАО09-09-2005 01:36 AM
Re: Reclaim disk space
and see if anyone has the file open.
You can set the output to a file and save the results.
show dev/file/out = t.t disk
search t.t file
That will kill it.
Check to see if it is installed.
install>
list
Those are the two most obvious reasons.
Otherwise the file will be marked for delete and you'll have to clean it up after a reboot, now it is marked or delete.
Good luck.
Bob Comarow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2005 06:27 PM
тАО09-11-2005 06:27 PM
Re: Reclaim disk space
I've tried to dismount the disk on the weekend and I was able to dismount the disk which tells me no user/process is locking any file on the disk.
After mounting the disk, the 16M block still not showing as free disk space.
Can reboot really fix this problem ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2005 06:48 PM
тАО09-11-2005 06:48 PM
Re: Reclaim disk space
how did you determine to loss space?
Antonio Vigliotti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2005 06:56 PM
тАО09-11-2005 06:56 PM
Re: Reclaim disk space
The only way you can be absolutly sure nobody uses the disk anymore is to dismount the disk on all nodes so it can no longer be accessed from ANY node. Dismounting it from one node may leave others a possibility to access the disk.
Little, VERY little chance reboot would solve the problem.
As stated by others and me previously, FIRST analyse ALL your system in the cluster, to the utmost extent. Not just SHOW DEV/FILES, ANALYZE/SYSTEM to check process information on open channels, locks etc. Try DFU as well to report on MFD.
If you can successfully dismount the disk from all nodes, mount it privately (on one) and execute $ ANALYZE/DISK/REPAIR and analyze it's outcome (including [SYSLOST]).
Last: like Hein said: if you expect the file to be in exactly the same space: forget it. The best you can get is restore the file in one contiguous file. (Or you must restore the file as the first on a newly initilaized disk, but even that would be impossible since, AFAIK, you cannnot control the location where a file is restored on disk).
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2005 06:57 PM
тАО09-11-2005 06:57 PM
Re: Reclaim disk space
It may, of course be something that "ate it" in one hit, so try a disk-wide dir/sel=siz=min=16MB (or something like that) to see if something has "eaten it" in one chunk.
failing that, a dir/since=
q
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-11-2005 09:45 PM
тАО09-11-2005 09:45 PM
Re: Reclaim disk space
16MB: is that the used size (DIR/SIZ) or the allocated size (DIR/SIZE=ALLOCATED)? In the latter case, you may have to loog for a larger size, depending on disk clustersize aned EXTENTSIZE parameter of the file itself. Since that is deleted, you won't be able to tell ;-(
No matter what: In the vast majority of situation, a file of that size will NOT be allocated in one chunk of blocks (AKA contiguous) but in a number of extents that can bre spread over the disk. So if you delete the file, the allocated space is freed for use. But you won't see as one 16Mb chunk of free space. One way to really find out is to $SHOW DEV/FULL immediately before and after deletion, and compare "free blocks". After deletion there should be 32M blocks more (more or less, since space might be occupied directly).
Only if a file has the attribute "Contiguous", deletion of a 16Mb file will free a chunk of 32M blocks that will show up as such.
(do a $ DUMP/HEADER/BLOCK=(COUNT:0)
Count: 8721 LBN: 11179503
Count: 843 LBN: 11244672
Count: 7086 LBN: 11275755
Count: 1653 LBN: 11282847
I have seen files with hundreds....(due to bad EXTENT attribute)))
So it is very well possible the blocks are freed, but in a number of chunks, (much) smaller then 32M blocks.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-12-2005 03:23 AM
тАО09-12-2005 03:23 AM
Re: Reclaim disk space
>> Can reboot really fix this problem ?
No.
Please explain to use how you determine 16M 'missing' free space.
Did you know exactly what was there before and after?
Is this all the space you have?
Where exactly does that backup and accidental delete enter the story?
Regards,
Hein.