Had a issue recently where DB admins did:

mv listener.log listener.log.old
gzip listener.log.old

Where file listener.log is continually being written to by an oracle process.

Anyway, according to the DB admins they successfully created the
listener.log.old.gz
file (i.e. all went okay).

Then they started complaining that space had not been freed on the filesystem.

I logged in and couldn't see the file listener.log.old.gz anywhere. The "listener.log", which was 2GB originally, was indeed smaller when I checked, so it was moved.

"du -ks /opt/sw/oracle" showed 4GB in use.

Whereas "df -k" showed 6GB in use on the "/opt/sw/oracle" mountpoint.

Apparently it's something to do with inodes referring to the original file while it's still in use ... but not sure, which is why I am posting to find out why?

Anyway, to fix the issue, stopping and restarting the process using the file will free up the space.

mv listener.log listener.log.old
name change doesn't matter, the file is already open. Process still writes to what is now listener.log.old

gzip listener.log.old
(listener.log.old.gz is created and listener.log.old is removed)
you removed the name, not the file. Another name change which doesn't matter.

A file will no link to a directory will be removed upon the last close.

What would probably work:
cp listener.log listener.log.old
cp /dev/null listener.log
gzip listener.log.old

Is that why I could not see the listener.log.old.gz file when I logged in to check?
If it is removed, then why isn't the space freed?

Thanks for the info btw.

No, I can't explain why the .gz file was missing.

fuser will show open files that have been deleted on a given file system. Until that process is stopped the space will not be freed. Before messing with files make sure no process has it open with fuser.