Why does the disk space remain unchanged after the file is deleted?

Why does the disk space remain unchanged after a file is deleted? First, we obtain a list of files that have been deleted but are still occupied by applications: Use the root user; # lsof | grep deletedora 25575 data 33u REG 65,65 4294983680 31014933/oradata/DATAPRE/UNDOTBS009.dbf (deleted) from lsof output, we can find that processes with a pid of 25575 hold the file/oradata/DATAPRE/UNDOTBS009.dbf opened with the file description number (fd) 33. After finding this file, we can end the process to release the occupied space. # Kill-9 25575 or # cd/root /. trash/# rm-rif * linux does not release space after deleting a file. Today, the home space of a server is full, so it is necessary to clear useless files. After I delete the file, no change in available space found OS: centos4.7 phenomenon: Current disk space usage: [root @ ticketb ~] # Df-hFilesystem Size Used Avail Use % Mounted on/dev/sda1 981 M 203 M 729 M 22%/none 16G 0 16G 0%/dev/shm/dev/sda9 2.9G 37 M 2.7G 2%/tmp/dev/sda7 4.9G 1.9G 2.7G 42%/usr/dev/sda8 2.9G 145 M 2.6G 6%/var/dev/mapper/vghome-lvhome20G 19G 11 M 100%/home/dev/mapper/vgoradata-lvoradata144G 48G 90G 35%/u01/oradata/dev/mapper/vgbackup-lvbackup193G 7.8G 175G 5%/u01/backup via the following command find useless files, then delete [root @ ticketb ~] # Find/home/oracle/admin/dbticb/udump/-name "dbticb _*. trc "-mtime + 50 | xargs rm-rf. Then, check the disk space usage and find that no/home space has changed. [root @ ticketb ~] # Df-hFilesystem Size Used Avail Use % Mounted on/dev/sda1 981 M 203 M 729 M 22%/none 16G 0 16G 0%/dev/shm/dev/sda9 2.9G 37 M 2.7G 2%/tmp/dev/sda7 4.9G 1.9G 2.7G 42%/usr/dev/sda8 2.9G 145 M 2.6G 6%/var/dev/mapper/vghome-lvhome20G 19G 11 M 100%/home/dev/mapper/vgoradata-lvoradata144G 48G 90G 35%/u01/oradata/dev/mapper/vgbackup-lvbackup193G 7.8G 175G 5%/u01/backup this depressing ah, how can I delete a file without releasing the space? The rm command should be used to delete the file directly. In addition, check the space occupied by/home [root @ ticketb ~] # Du-h -- max-depth = 1/home16K/home/lost + found2.6G/home/oracle2.6G/home. The space has been released, reason for not releasing disk space: in Linux or Unix systems, deleting a file through rm or file manager will remove the link from the directory structure of the file system (unlink ). however, if the file is opened (one process is in use), the process can still read the file, and the disk space is still occupied. When I delete the oracle Alert log File, the file should be used to obtain a list of files that have been deleted but are still occupied by the application, as shown below: [root @ ticketb ~] # Lsof | grep deletedoracle 12639 oracle 5 w REG 253,0 648 215907/home/oracle/admin/dbticb/udump/dbticb_ora_12637.trc (deleted) oracle 12639 oracle 6 w REG 253,0 16749822091 215748/home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted) oracle 12639 oracle 7u REG 36282, 0 0 12639/home/oracle/product/10.2.0/db_1/dbs/lkinstdbticb (deleted) oracle 16749822091 oracle 8 w REG 253,0 215748/home/ Oracle/admin/dbticb/bdump/alert_dbticb.log (deleted) oracle 12641 oracle 5 w REG 253,0 648 215907/home/oracle/admin/dbticb/udump/dbticb_ora_12637.trc (deleted) oracle 12641 oracle 6 w REG 253,0 16749822091 215748/home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted )... Oracle 23492 oracle 6 w REG 253,0 16749822091 215748/home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted) oracle 23492 oracle 7u REG 36282, 0 0/home/oracle/product/10.2.0/db_1/dbs/lkinstdbticb (deleted) oracle 23492 oracle 8 w REG 16749822091, 0 215748/home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted) oracle 23494 oracle 10u REG 36307, 0 0 10.2/home/oracle/product/. 0/db_1/dbs/lkinstrmandb (deleted) from the output result, we can see that/home/oracle/admin/dbticb/bdump/alert_dbticb.log is still in use. How can the process be released if the space is not released? One way is to kill the corresponding process, or stop the application that uses this file, so that the OS can automatically reclaim disk space. In this environment, many processes are using this file, stopping a process is a little troublesome, and there is a high risk that when a file is opened in linux, the Linux kernel creates a directory named "pid" for each process in/proc/"/proc/nnnn/fd/directory (nnnn is pid)" to save the process information, the sub-directory fd stores the fd (fd: file descriptor) of all files opened by the process ). By truncating files in the proc file system, the kill process forcibly requires the system to recycle the files allocated to being used. This is an advanced technology that is only used when the Administrator determines that it will not affect running processes. The application does not support this method well. When a file in use is truncated, unpredictable problems may occur, for example, according to the previous lsof output: 1. $ file/proc/25575/fd/332. /proc/25575/fd/33: broken symbolic link to '/oradata/DATAPRE/UNDOTBS009.dbf (deleted)' 3. $ echo>/proc/25575/fd/33 so I still use stop application to solve the restart oracle database, we found that the space corresponding to/home/oracle/admin/dbticb/bdump/alert_dbticb.log was released and the disk space usage was viewed. We found that the space has been recycled [root @ ticketb ~]. # Df-hFilesystem Size Used Avail Use % Mounted on/dev/sda1 981 M 203 M 729 M 22%/none 16G 0 16G 0%/dev/shm/dev/sda9 2.9G 37 M 2.7G 2%/tmp/dev/sda7 4.9G 1.9G 2.7G 42%/usr/dev/sda8 2.9G 145 M 2.6G 6%/var/dev/mapper/vghome-lvhome20G 2.6G 16G 15%/home/dev/mapper/vgoradata-lvoradata144G 48G 90G 35%/u01/oradata/dev/mapper/vgbackup-lvbackup193G 7.8G 175G 5%/u01/backup