1748279 Members
4128 Online
108761 Solutions
New Discussion юеВ

Re: Reclaim disk space

 
Phil.Howell
Honored Contributor

Re: Reclaim disk space

Would this happen if the rms file has global buffers (unlikely if it's an archive, but you never know)
Phil
Hein van den Heuvel
Honored Contributor

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.
Robert Gezelter
Honored Contributor

Re: Reclaim disk space

rison so,

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
comarow
Trusted Contributor

Re: Reclaim disk space

On all nodes of the cluster, do a show dev/files
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
rison so_1
Advisor

Re: Reclaim disk space

First, Thanks for all your help.


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 ?
Antoniov.
Honored Contributor

Re: Reclaim disk space

Hi Rison,
how did you determine to loss space?

Antonio Vigliotti
Antonio Maria Vigliotti
Willem Grooters
Honored Contributor

Re: Reclaim disk space

Dismount - on one node or for all the nodes in the cluster?
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).
Willem Grooters
OpenVMS Developer & System Manager
Peter Quodling
Trusted Contributor

Re: Reclaim disk space

If you have "disconnected" all I/O by dismounting, flushed all "half done bits etc" with an anal/disk/repair, then the remaining answer is that some other application has "eaten your 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= to see what has been created since, and whether it adds up to 16MB.

q
Leave the Money on the Fridge.
Willem Grooters
Honored Contributor

Re: Reclaim disk space

A few more questions amnd hints:
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) on a big file, you may see multiple retrieval pointers (this is a 18K block file):
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.


Willem Grooters
OpenVMS Developer & System Manager
Hein van den Heuvel
Honored Contributor

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.