Full file systems occur in practice again and again, everyone knows this. Usually you search for large files or directories and check if older data can be deleted to make space again (but sometimes the file system will be simply enlarged without further investigation). In some cases, however, you can not find any larger files that could be deleted or you discover that file system space is seems to be gone, but you can not identify where this space is used. The command du then displays a smaller value for the file system space used than df. In the following, such an example is shown, as well as the hint how to identify where the filesystem-space is and how it can finally be recovered. AIX has a nice feature to offer that is not found in most other UNIX derivatives.
The file system /var/adm/log is 91% filled, currently 3.6 GB of the file system are in use:
# df -g /var/adm/log Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/varadmloglv 4.00 0.39 91% 456 1% /var/adm/log #
A quick check with the command du shows that apparently much less space is occupied:
# du –sm /var/adm/log 950.21 /var/adm/log #
The command “disk usage” shows only 950 MB occupied space! This is 2.7 GB less than the value from the df command. But where is the missing space?
The difference comes from files that have been deleted but are still open by at least one process. The entry for such files is removed from the associated directory, which makes the file inaccessible. Therefore the command du does not take thes files into account and comes up with a smaller value. As long as a process still has the deleted file in use, however, the associated blocks are not released in the file system, so df correctly displays these as occupied.
So there is at least one file in the file system /var/adm/log which has been deleted but is still open by a process. The question is how to identify the process and the file.
AIX provides an easy way to identify processes that have opened deleted files, the fuser command supports the -d option to list processes that have deleted files open:
# fuser -d /var/adm/log /var/adm/log: 9110638 #
If you also use the -V option, you will also see information about the deleted files, such as the inode number and file size:
# fuser -dV /var/adm/log /var/adm/log: inode=119 size=2882647606 fd=12 9110638 #
The output shows that here the file with the inode number 119 with a size of approximately 2.8 GB was deleted, but is still opened by the process with the PID 9110638 over the file descriptor 12.
Using ps you can quickly find out which process it is:
# ps -ef|grep 9110638 root 9110638 1770180 0 Nov 20 - 28:28 /usr/sbin/syslogd root 8193550 8849130 0 09:13:35 pts/2 0:00 grep 9110638 #
In our case it is the syslogd process. Presumably a log file was rotated via mv without informing the syslogd (refresh -s syslogd). We fix this shortly and check the file system again:
# refresh -s syslogd 0513-095 The request for subsystem refresh was completed successfully. # # df -g /var/adm/log Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/varadmloglv 4.00 3.07 24% 455 1% /var/adm/log #
The output shows that the file system blocks have now been released.