Deleted files still occupies space
danpel
If I delete a file, that some process have an open filedescriptor to,
the space which the file occupies will not be freed in the filesystem.
Now, I can't see who has the file open, because I have no file to do
"fuser" on (remember, I deleted it). Of course I can always boot, but I
would rather know how to free the space WITHOUT reboot.
Does anyone know this?
Ken Wallis
>If I delete a file, that some process have an open filedescriptor to,
>the space which the file occupies will not be freed in the filesystem.
That's because it isn't really unlinked until the last file descriptor
closes.
>Now, I can't see who has the file open, because I have no file to do
>"fuser" on (remember, I deleted it). Of course I can always boot, but I
>would rather know how to free the space WITHOUT reboot.
Yes, a reboot is a pretty broadband way of making sure all file descriptors
are closed!
Why not do an fuser on files BEFORE deleting them? You could even set up an
alias for rm which could automatically do this for you and warn you if you
were about to delete an open file.
HTH,
Ken Wallis
Empower Data Solutions Pty Limited, ACN 079 955 196
Envision, enable, enhance... empower
cyb...@my-dejanews.com
p...@dannet.dk wrote:
> Hello,
>
> If I delete a file, that some process have an open filedescriptor to,
> the space which the file occupies will not be freed in the filesystem.
>
> "fuser" on (remember, I deleted it). Of course I can always boot, but I
> would rather know how to free the space WITHOUT reboot.
>
>
From the incredibly useful apar database, available from all good browsers at:
http://service.software.ibm.com/cgi-bin/support/rs6000.support/databases
Resolving Space Taken by Open Files That Have Been Deleted
In this second case, there are files within the filesystems that are opened by
applications, but have been removed from the filesystem tree.
This behavior is documented in the 'unlink()' system call as follows:
When all links to a file are removed and no process has the file open, all
resources associated with the file are reclaimed, and the file is no longer
accessible. If one or more processes have the file open when the last link is
removed, the directory entry disappears.
However, the removal of the file contents is postponed until all references to
the file are closed.
You can use the 'fuser' command with the "-dV" flag on the full path to the
device the filesystem resides on. This will indicate files that have been
removed but are still open. It will also report the inode number and size of
such files. Using the process ID returned for these files, the source
application can either be instructed to close these files or the application
can be exited. Once this has occurred, and 'fuser' no longer shows this
deleted file, then the space will be returned to the filesystem for general
use.
Note: Using he flags given for 'fuser' require enhancements for 'fuser' to be
installed for the appropriate release of AIX, as listed below. Other fixes may
be needed in addition to these to reliably perform the operations of this
document. Please refer to the list at the end of this document.
APAR Description AIX Level
---- ----------- ---------
IX78943 ENHANCEMENTS TO FUSER 4.1
IX78941 ENHANCEMENTS TO FUSER 4.2
IX78523 ENHANCEMENTS TO FUSER 4.3
Some information specific to this release of 'fuser' follows:
The fuser command lists the process numbers of local processes that use the
local or remote files specified by the File parameter. For block-special
devices, the command lists the processes that use any file on that device.
Each process number is followed by a letter indicating how the process uses
the file: c Uses the file as the current directory. e Uses the file as a
programs executable object. r Uses the file as the root directory. s Uses
the file as a shared library (or other loadable object).
If no letter is specified, the process uses the file as a regular open file.
The following flags are new to the function of 'fuser':
Note: The '-c' and '-f' flags currently exist in AIX 4.3.
-c Reports on any open files in the file system containing File.
-f Reports on open instances of File only.
-x Used in conjunction with -c or -f, reports on executable and
loadable objects in addition to the standard fuser output.
-d Implies use of -c and -x flags. Reports on any open files which
haved been unlinked from the file system (deleted from the
parent directory). When used in conjunction with the -V flag,
also reports the inode number and size of the deleted file.
-V Provides verbose output.
Recommended Fixes
APAR Description AIX Level
---- ----------- ---------
IX78066 FSCK SHOULD PATCH UP ALLOCATIONS IN WMAP 4.3
IX78873 MALLOC FAILED ERRORS FROM FUSER 4.3
IX76061 DEFRAGFS AND FSCK INCORRECTLY REPORT BAD BIT MAP 4.2
IX77541 FSCK SHOULD PATCH UP ALLOCATIONS IN WMAP 4.2
SPECIAL NOTICES
Please use this information with care. IBM will not be
responsible for damages of any kind resulting from its use.
The use of this information is the sole responsibility of
the customer and depends on the customer's ability to eval-
uate and integrate this information into the customer's
operational environment.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
sysadmin
root /u/joe>fuser -dV /dev/hdisk0
fuser: Not a recognized flag: d
? option ignored.
fuser: Not a recognized flag: V
? option ignored.
/dev/hdisk0:
--
===========================================
Opinions my own and not representative of my employer
Do not listen to me: I have brain damage
===========================================
"Spock! We're talking about millions of lives!"
Spock (raised eyebrow) "Nevertheless, if the Romulans are indeed an offshoot
of Vulcan blood,... it is imperative we attack."
cyb...@my-dejanews.com wrote in message <74oc51$3ne$1...@nnrp1.dejanews.com>...
Hemant Shah
:)Hello,
:)If I delete a file, that some process have an open filedescriptor to,
:)the space which the file occupies will not be freed in the filesystem.
:)Now, I can't see who has the file open, because I have no file to do
:)"fuser" on (remember, I deleted it). Of course I can always boot, but I
:)would rather know how to free the space WITHOUT reboot.
:)Does anyone know this?
Get the latest version of lsof from:
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof
--
Hemant Shah /-------------------\ ^~~~~^
E-mail: sh...@xnet.com |TECHNOLOGY | | |
|No place for wimps | o|-OO-|o
TO REPLY, REMOVE no_junk_mail | -Dilbert |--- | () |
FROM MY E-MAIL ADDRESS. \-------------------/ | |
-----------------[DO NOT SEND UNSOLICITED BULK E-MAIL]------------------
I haven't lost my mind, Above opinions are mine only.
it's backed up on tape somewhere. Others can have their own.
si...@nospamwaikato.ac.nz
> If I delete a file, that some process have an open filedescriptor to,
I favour the meglomanic approach of blind kill -9's of anything I
think might be holding the file open. After all, it's their fault
for causing me all this work in the first place.
--
Simon Travaglia, Email without auto spam rejection at by removing the
anti-spam text from the above email address. But not root@localhost,
nor ro...@127.0.0.1, nor postmaster@locahost, not abuse@localhost
http://mrjolly.cc.waikato.ac.nz Ph: +64 7 838-4709 Fax: +64 7 838-4066
University of Waikato, Private Bag 3105, Hamilton, New Zealand..
Mukesh Purohit
Try this ...
umount <file system which contains deleted file>
if this gives an error like .."cann't unmount , busy" etc ...then
umount <Logical Volume name e.g /dev/lv01>
And then mount the file system . I have tried this & it works.
-Mukesh Purohit
danpel wrote:
> Hello,
>
> If I delete a file, that some process have an open filedescriptor to,
> the space which the file occupies will not be freed in the filesystem.
>
> Now, I can't see who has the file open, because I have no file to do
> "fuser" on (remember, I deleted it). Of course I can always boot, but I
> would rather know how to free the space WITHOUT reboot.
>
> Does anyone know this?
Scott L. Fields
It clearly states that to use these new options, you must have
the requisite APARS installed.
Note: Using the flags given for 'fuser' require enhancements for 'fuser' to
be installed for the appropriate release of AIX, as listed below. Other
fixes
may be needed in addition to these to reliably perform the operations of
this
document. Please refer to the list at the end of this document.
APAR Description AIX Level
---- ----------- ---------
IX78943 ENHANCEMENTS TO FUSER 4.1
IX78941 ENHANCEMENTS TO FUSER 4.2
IX78523 ENHANCEMENTS TO FUSER 4.3
Also, use the device the logical volume name, NOT
the hdisk. (ie, to see what was deleted but open in /tmp,
run "fuser -dV /dev/hd3")
sysadmin wrote in message <74p9gn$s...@bgtnsc02.worldnet.att.net>...
Scott L. Fields
"unmount" does the equivelant of a "slibclean", which would cause
an inactive library to be pulled from the loader list, and thus closed,
and this will free the space.
Try running "slibclean" instead of an "unmount". If this results in the
space
going up, then that was the issue. Remember, it has to be a INACTIVE
shared library.
By the way, if it were active, the new "fuser" should spot it as well.
Mukesh Purohit wrote in message <36703D64...@bowne.com>...
Matthew Hannigan
The new AIX fuser options sound great.
But if you don't have that, and don't have lsof or similar..
List all processes using the mount point with 'fuser -c'
and iterate through those, and eyeball 'em for the offender.
Can take a bit of guessing..
i.e. something like this on Solaris:
for p in `fuser -c /mountpoint`
do
ps -fp $p | tail +2
done
Another tool which may help you on Solaris is /usr/proc/bin/pfile;
if you can figure out how to get the name from the ino.
Of course prevention is better than a cure; what/who
is removing the files too soon?
--
- Matt
cyb...@my-dejanews.com
"sysadmin" <charles...@worldnet.att.net> wrote:
> Doesn't seem to be working
>
> root /u/joe>fuser -dV /dev/hdisk0
> fuser: Not a recognized flag: d
> ? option ignored.
> fuser: Not a recognized flag: V
> ? option ignored.
> /dev/hdisk0:
>
> --
> ===========================================
> Opinions my own and not representative of my employer
> Do not listen to me: I have brain damage
> ===========================================
> "Spock! We're talking about millions of lives!"
> Spock (raised eyebrow) "Nevertheless, if the Romulans are indeed an offshoot
> of Vulcan blood,... it is imperative we attack."
a) Read the document, check if you have the required patch, downloading and
installing it if required, then trying the command options.
or
b) Just try it, it didn't work, call for help.
Jacob Langford
> Hello,
>
> If I delete a file, that some process have an open filedescriptor to,
> the space which the file occupies will not be freed in the filesystem.
>
> Now, I can't see who has the file open, because I have no file to do
> "fuser" on (remember, I deleted it). Of course I can always boot, but I
> would rather know how to free the space WITHOUT reboot.
>
> Does anyone know this?
When this happened to me, I just used fsck to fix things up. Then when
I shut the system down, there was a bit of grumbling from somewhere,
about something related to those file descriptors, but no real problems.
Jacob (lang...@uiuc.edu)
danpel
Also, someone (tanks DW :-) told me I could do:
The command /usr/sbin/pstat -i lists out all open files, whether or
not they've
been deleted. ( Similar to the lsof utility someone mentioned ). The
output needs
a bit of interpretation. It gives the major and minor keys of the device
on which
the filesystem resides ( do an ls -l /dev/lvname to find out the major
and minor
keys of logical volume lvname ), the uid, gid, inode and size of the
file.
There are options ( I think ) to reduce the volume of output. Otherwise
you can use
grep, awk and sort to perhaps find the largest files, or the files owned
by a
particular user etc. Note that the uid and gid are of the owner of the
file, not of
the current user of the file.
This might give you clues as to who is actually using the file at the
time, so that
you can kill these processes. The file will then be really deleted.
John Riddoch
>
> Hello,
>
> If I delete a file, that some process have an open filedescriptor to,
> the space which the file occupies will not be freed in the filesystem.
>
> Now, I can't see who has the file open, because I have no file to do
> "fuser" on (remember, I deleted it). Of course I can always boot, but I
> would rather know how to free the space WITHOUT reboot.
>
> Does anyone know this?
If you can, umount the file system, fsck it and remount. Given that a
process still has an open filehandle, that may not work...
--
John Riddoch Email: j...@scms.rgu.ac.uk Telephone: (01224)262730
Room C4, School of Computer and Mathematical Science
Robert Gordon University, Aberdeen, AB25 1HG
Any sufficiently advanced technology is indistinguishable from a rigged
demo.
Robert D. Keys
>> If I delete a file, that some process have an open filedescriptor to,
>> the space which the file occupies will not be freed in the filesystem.
>>
>> Now, I can't see who has the file open, because I have no file to do
>> "fuser" on (remember, I deleted it). Of course I can always boot, but I
>> would rather know how to free the space WITHOUT reboot.
>>
>> Does anyone know this?
> When this happened to me, I just used fsck to fix things up. Then when
> I shut the system down, there was a bit of grumbling from somewhere,
> about something related to those file descriptors, but no real problems.
I am curious, and a bit of the geek unix newbie.....
Regarding open but tied up file space as open file descriptors.....
1. If the space is down below the root of a file system, can it
merely be rm -fR'd from the next level up the tree to clear any
open file descriptors?
2. If the space is at the root of a file system or below, can it
be dumped and restored to clear any open file descriptors?
3. If the space is anywhere, and mixed with files to be conserved,
can it merely be tarred off, the file system section rm -fR'ed
from one level up and then the directory recreated and the tarball
unrolled back in place?
I though I remembered reading something in the BSD smm about that kind
of space being tied up and the recommended way to remove it was to
rm -fR, from one level up, the affected section of the tree.
Any insights are appreciated.
Bob Keys
Barry Margolin
Robert D. Keys <bsd...@seedlab1.cropsci.ncsu.edu> wrote:
>1. If the space is down below the root of a file system, can it
> merely be rm -fR'd from the next level up the tree to clear any
> open file descriptors?
No. The deleted file isn't referenced in any directory entries, so
deleting the directories won't have any effect on it.
>2. If the space is at the root of a file system or below, can it
> be dumped and restored to clear any open file descriptors?
No. Dump will only dump files that have directory entries, and restore
will only restore those files. Deleted files will be unaffected.
>3. If the space is anywhere, and mixed with files to be conserved,
> can it merely be tarred off, the file system section rm -fR'ed
> from one level up and then the directory recreated and the tarball
> unrolled back in place?
Again, the file isn't mentioned in any directories, so nothing you do to
directories will have any effect on it. A deleted file is referenced only
by an anonymous inode, which is kept alive by the open file descriptors.
The only way to make it go away is for the process(es) that have it open to
close it. Killing the processes will force this to happen, and rebooting
the system will force all processes to be killed (and if they don't go
gracefully, the fsck during the reboot will clear up the space).
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
Curtis L. Brown
>
> Hello,
>
> If I delete a file, that some process have an open filedescriptor to,
> the space which the file occupies will not be freed in the filesystem.
>
> Now, I can't see who has the file open, because I have no file to do
> "fuser" on (remember, I deleted it). Of course I can always boot, but I
> would rather know how to free the space WITHOUT reboot.
>
> Does anyone know this?
Two possible avenues to find the process that still has the file open:
1) As you observed you have no file to do "fuser" on but you can do
fuser on the whole filesystem and thereby determine the process. "fuser
/dev/{fsname}". This can be a real pain if a lot of processes have
files open in this file system.
2) "lsof" can also be of help here. Especially if there are a lot of
processes as in 1). You may be able to pass the result of lsof through
a filter to eliminate those processes that have files indicated and find
only those/that which do not.
<on soapbox>
Of course you could have just truncated the file with "cat /dev/null >
{filenmae}" and avoided the whole problem.
<off soapbox>
Good luck.