This is routine on Unix. When you "move" a file to another filesystem, it is actually copied and then unlinked from its source filesystem. But unlink does not necessarily free the space. The unlink(2) man page says ...
unlink deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open the file is deleted and the space it was using is made available for reuse. If the name was the last link to a file but any processes still have the file open the file will remain in existence until the last file descriptor referring to it is closed.To find out which processes are using a file prior to unlinking it, you can use the fuser command.
We had a situation where one of our disks holding data files got 100% filled up. I took one of the tablespaces offline and moved approximately 4.5 GB worth of data files to another disk and was able to successfully bring up the tablespace online. However, the stats (df -k) of that disk were still showing 100% usage. I have seen this situation in the past where after bouncing the database and clearing out all sqlnet processes (at the OS level) helped release the space. Would you be able to shed some light on the cause of this. Also, is it possible to see who was holding locks on those moved data files. We are running 8.1.6 on Solaris 2.6.