There is a procedure that has stirred some debate amongst our team.
We agree here: If a file is removed while allocated, the space is not freed.
Example of large file statically allocated:
unix178:# fuser BIG.log
unix178:# ls -l BIG.log
-rw-r--r-- 1 ivmgr ivmgr 1255292755 Sep 11 10:15 BIG.log
unix178:# df -Pm .
Filesystem MB blocks Used Available Capacity Mounted on
/dev/hd9var 1536.00 1372.28 163.72 90% /var
If BIG.log is removed, the inode is still allocated, and thus, no disk space is freed, until the process ends, or closes it's files.
Here's the question:
We have two methods discussed, to free the disk space.
Group 1 does not like touching "active" files with a redirect(>),
Group 2 says "it appears to work fine".
Here's the steps for the two methods.
mv BIG.log BIG.log-YYMMDD.HHMMSS
touch BIG.log # (optionally chmod/chown if required to make match original)
mv BIG.log-YYMMDD.HHMMSS /archive
### the Filesystem space is truly freed.
cat BIG.log > /archive/BIG.log-YYMMDD.HH
### The Filesystem space does appear to be freed.
Assuming the risk of loosing a couple of log records using method 2 (that may have been created between the end of the cat command, and the redirect) is acceptable
Pro for Method 1: * absolutely no records are lost
* No Risk of orphaned inodes (if steps followed properly)
Con for method 1: * Causes application outage
* More commands, risk of a new admin orphaning an inode.
Is there any reason to avoid method 2?
Is there a risk of "confusing" a program that has a file allocated, by issuing a redirect to it's file?