ls and du disagreement

I wrote a script to do log rotation for a Weblogic Application.

The file is permanetly written to and grows fast. The filesystem size forbid to make a copy of the file.

Mainly the script in crontab does just this :

cat FILE | gzip > ARCHIVE && cat /dev/null > FILE

Now, ls and du show very different info :

ll FILE

-rw-r--r--1 weblogic web1740727500 Mar 21 10:53 FILE

This is the former size of the file before it was purge

du -k FILE

1824FILE

This should be it's real size

I tried a little C program based on <sys/stat.h>

lsinod FILE

File : FILE

inode 254713 on ufs filsystem with block_size of 8 ko

- rw- r-- r--UID=5000GID=500 Link(s) 1

1740728538 byte(s) 3648 block(s)

Last readed : Fri Mar 21 10:44:09 2003

Last writed : Fri Mar 21 10:53:27 2003

tail works find on FILE, head takes unusual time to complete

df -k on the filesystem shows the space occupied by the file was freed.

=> What would be you diagnostic ?

[1084 byte] By [NDumeige] at [2007-11-25 23:20:48]
# 1

The file was open to another process when you truncated the log file.

When the application wrote it's next entry, it continued writing from where it left off and unfortunately, this has left a huge hole at the beginning of the file.

Under UFS, the hole takes a tiny amount of space even though 'ls -l' makes it look like the file is huge.

If you can't get the application to close the logfile when you are trying to rotate the logs (or ideally when it's finished writing each log entry), you're going to have to shut it down, archive and then restart the app.

The reason 'head' takes soo long is it's looking for the first few lines of the file - it has to read through about 1738MB of 0s before it gets to the first line.

Basically, what you've got here is a sparse file.

Sorry there's no good news here....

--A.

AndrewNess at 2007-7-5 18:08:38 > top of Java-index,General,Talk to the Sysop...