Linux文件删除原理

在Linux文件系统中，文件的删除操作涉及到两个核心的概念i_nlink和i_count，当执行rm命令删除文件时，Linux内核并不是立即将文件数据从磁盘中擦除，而是进行以下操作：

1、删除文件：执行rm命令删除文件，这会导致文件的链接数（i_nlink）减少。

2、检查链接数：如果文件的链接数（i_nlink）减少到0，表示没有其它文件指向它。

3、检查引用数：如果文件的链接数（i_nlink）为0，但引用数（i_count）不为 0，说明文件仍然被某些进程打开并使用。在这种情况下，文件的数据和inode不会立即被删除，而是继续保留，直到所有引用该文件的进程关闭该文件（即i_count减少到0）。

4、释放资源：只有当文件的链接数（i_nlink）和引用数（i_count）都为0时，文件系统才会真正释放该文件的inode和数据块，将其标记为可用，以便将来存储新的数据。

i_nlink和i_count

i_nlink（链接数）：当前有多少个硬链接指向这个文件的inode，当执行rm命令删除文件时，i_nlink链接计数会减少。如果链接计数减少到0，并且没有进程引用该文件（即i_count等于0），那么该文件会真正的被删除。

i_count（引用数）：当前有多少个进程正在引用该文件的inode，即使i_nlink减少到0，只要有进程仍在使用该文件（比如文件被打开），i_count仍然会大于0，此时文件的实际数据和inode依旧存在，未被释放。

---

举例：模拟MySQL空间不释放问题分析

以MySQL数据库日志为例，模拟日志爆满并删除日志，空间无法释放。

我这里生成一个10GB文件写入MySQL error.log中，打满磁盘（我这里磁盘10GB）

执行删除操作

删除文件后，查看磁盘空间

神奇的情况出现了，磁盘使用率依旧是100%，空间并没有被释放，但是我们的的确确删除了error.log，所以此时我们就可以得出来一个结论，error.log并没有真正的被删除，即i_count≠0。

---

i_nlink查看方法

查看i_nlink的值非常容易，我们只需要执行ls -l命令即可。

例如：查看当前目录下demo文件的i_nlink值，并通过硬链接增加i_nlink值。

这里的数字1，就表示i_nlink值为1。

通过ln对该文件创建硬链接，那么此时i_nlink值就变为2了。

通过ls -il查看demo和demo2的inode值相同，因为是通过硬链接创建的文件，这意味着这两个文件实际上是同一个文件，即它们指向同一个物理数据块，在这种情况下，对其中一个文件的修改会影响到另一个文件，因为它们共享相同的内容。如果rm删除其中一个文件，那另一个文件的i_nlink值就会减1，即i_nlink值为1。

i_count查看方法

i_count是内核内部的一个计数器，通常用于跟踪有多少个进程当前打开了这个文件。这个计数器并不直接暴露给用户空间，因此没有直接的命令可以查看i_count的值。

但是我们可以通过一些间接的方法来了解哪些进程打开了某个文件，这可以帮助你推测i_count的值。

lsof命令可以列出所有打开的文件以及它们被哪个进程打开。

fuser命令也可以用来列出正在使用某个文件的进程，显示正在使用该文件的进程ID列表。

例如：通过tail命令打开demo文件

通过lsof命令

COMMAND：使用该文件的进程名，这里是 tail。
PID：进程标识符，这里是 2679202。
USER：拥有该进程的用户，这里是 root。
FD：文件描述符，这里是 3r，表示文件描述符是 3，并且是以只读的方式打开（r）。
TYPE：文件类型，这里是 REG，表示这是一个常规文件。
DEVICE：设备号，表示该文件所在的设备，这里是 253,0。
SIZE/OFF：文件大小或偏移量，这里是20K。
NODE：文件的 inode 号，这里是 33559053。
NAME：文件的名称，这里是 demo，表示正在访问的文件名。

综合来看，这个输出结果表明，root用户使用tail命令正在以只读方式访问名为demo的常规文件，进程ID为2679202。

通过fuser命令

root用户使用tail命令，正在以读取或写入的方式访问/root/demo文件，进程ID 2677467，但没有其他权限。

通过lsof和fuser这两个命令可以看出，当前只有一个进程占用，所以可以说i_count值等于1。

如果此时rm删除demo文件，那么i_nlink值减1。假设此时i_nlink值等于0，只要当前tail进程依旧打开着demo文件（i_count值不等于0），那么demo文件依旧存在于系统中，并没有真正的被删除，我们还可以通过一些方法来恢复demo文件。

---

i_count≠0文件能否恢复

通过前面的讲解，现在我们应该知道一个文件是否被删除，需要同时满足i_nlink=0和i_count=0。

在文件被删除后，i_count不等于0，文件的数据块可能不会立刻被释放或者重写，因为系统认为inode仍然在使用中，所以此时有一定概率可以成功的恢复被删除的文件。

但即使i_count不等于0，并不能保证你总能成功地恢复被删除的文件。这里有几个原因：

1、文件系统的差异：不同的文件系统（如ext4, XFS, Btrfs等）处理删除文件的方式有所不同。某些文件系统可能会更快地回收并重用inode和数据块。

2、数据覆盖：如果数据块已经被其他文件部分或完全覆盖，原始数据可能已不复存在。

3、工具和权限：恢复文件需要适当的工具和系统权限。某些恢复工具可能无法正确地解析残留的文件系统数据，特别是在文件系统受损或非常满的情况下。

4、文件的状态：即使inode未被回收，文件内容可能已经开始被操作系统覆盖，特别是在高IO操作的系统中，被删除文件的数据块很快就会被重新分配和使用。

虽然i_count 不为0增加了恢复文件的可能性，但这并不是一个绝对的保证。如果文件很重要，最好的策略是定期备份数据，并在删除任何重要文件之前仔细确认。在文件删除之后，如果需要恢复，最好尽快进行，以减少数据被覆盖的风险，并使用可靠的数据恢复工具来增加成功的机会。

i_count≠0文件恢复演示

ibdata1文件是MySQL数据库中InnoDB存储引擎的一个重要文件，网上有些文章讲到MySQL空间清理时，会告诉大家该文件过大可以删除，实际这样做法是错误的，假设如果你真的这么做了，千万不要重启，在不重启的情况下，有一定概率可以找回，但是一旦重启MySQL，ibdata1文件可能就真的没了。

演示过程如下：

1、通过wlnmp源安装MySQL8.0

我这里以RockyLinux8为例，wlnmp源使用见https://www.wlnmp.com/install

2、删除ibdata1

注意：删除后不要重启MySQL，重启后该文件的进程将被释放，文件将会真正的被删除。

3、查找i_count

得到PID 44901

4、找回ibdata1

此时ibdata1文件就被找回了，可以通过这个例子进行举一反三，但是就像我们前面所讲的那样，并不能保证你总能成功地恢复被删除的文件。

总结

在Linux文件系统中，当执行rm命令删除文件时，系统并不会立即擦除文件数据，而是通过减少文件的链接数（i_nlink）和引用数（i_count）来管理文件的删除过程。只有当这两个计数都为0时，文件的数据和inode才会被真正释放。

这种设计确保了即使文件被删除，只要有进程在使用它，文件数据仍然可以被访问，直到所有引用它的进程都关闭文件为止。

原文链接：Linux文件删除原理，转载请注明来源！