The root file system on my Solaris Unix server was low on free space, it was 98% full. Upon investigation I found out that there was a very large file 1.8 G in size. This file nohup.out was created by the Tivoli backup job. I could tell that it was created by Tivoli by reading the content. If you try and open a very large file with Vi, it will probably fail, because of the file size limitation. This limitation applies to Word, Excel, Notepad and most word processor.
To read the content of the large file I used the tail command to read the last few lines of the file. Tail -50 filename will display the last 50 lines of the file. You can also use the cat command, the head command will display the first few lines of the file. The tail command is part of most Unix and Linux, but not Windows. The windows version is available on the windows 2003 resource kit.
Back to the original issue, I made a copy of the file first to a remote disk drive. The deleted the file with the command rm filename. I thought I was done and I would instantly have 1.8G more free space. I check the disk space with the command df -h /, but the file system was still 98% full. This was strange, I listed the files in the directory, nohup.out was definitely not listed, it had been deleted.
Although the file appeared to have been deleted, it was still taking up space. This condition exists when the file is being used by an application or process running in the background. A reboot of the server would reclaim the free space, but a better way would be to simply restart the offending application or process. Sometimes the fuser command will display the process that has the file open, but in this case it did not. I do not know why fuser did not display the process but I knew it was the Tivoli client because that was the only entry in the nohup.out file. In this case restarting the Tivoli client reclaimed the free space.
1 comment for “Deleting a large file does not free up space in Unix.”