系统管理员的手中，管理着企业最有价值的资产——数据；而占据企业级服务器操作系统市场半壁江山的 Linux，更是让 Linux 系统管理员成为最重要的资产管理员。管理员的职责，就是让有限的 IT 资源，存储最有价值的数据。1991 年 IBM 推出 3.5 英寸 1GB 硬盘的时候，管理员洞悉硬盘上的每个文件，人工就可以实现文件管理；而今天 PB 级的存储设备，则给文件管理带来了前所未有的挑战。
文件删除操作，用过 Linux 的人都应该可以完成。那么以下这些文件删除操作，你能完成哪些？
- 删除整个文件系统中以特定后缀结尾的文件
- 在一个有 1 百万的文件系统中删除某个指定文件
- 从一个千万级的文件系统里，删除指定日期创建的 10 万个文件
- 在亿级文件系统里，每天执行文件系统清理，删除 1 年前产生的上百万文件
下面要讨论就是如何实现以上文件删除操作的策略和方法，如果以上操作对你来说轻而易举，可以忽略本文。
对于清理文件系统而言，我们可以简单的把清理任务分成两大类，清理过期文件和清理垃圾文件。
- 过期文件任何数据都有自己的生命周期，数据的生命周期曲线告诉我们，数据在产生和产生之后的一段时间内的价值最大，然后数据价值随着时间衰减。当数据生命周期结束时，就应该删除这些过期文件，将存储空间释放出来留给有价值的数据。
- 垃圾文件系统运行过程中，会产生各种各样的临时文件，些应用程序运行时的临时文件，系统错误产生的 Trace 文件，Core Dump 等等，在这些文件被处理后，就失去了保留价值，这些文件可以统称为垃圾文件。及时清理垃圾文件，有助于系统维护和管理，保证系统稳定有效的运行。
文件自动清理的概述
文件自动清理的特点与方法
在指定绝对路径下删除一个文件，rm 就可以实现；如果只知道文件名，不知道路径，我们可以通过 `find` 找到它，然后删除。推而广之，如果我们可以根据预设的条件找到指定文件，我们就可以实施删除操作。这也就是文件自动清理的基本思路，根据预设条件生成待删 除文件列表，然后执行定期清除任务实施删除操作。
对于过期文件而言，他们共同标志是时间戳，根据不同的文件系统，可能是文件创建时间，访问时间，过期时间等不同的时间属性。由于过期文件大多存在于 归档系统上，这类文件的特点是数量巨大，对于大型系统而言，每天的过期文件数量都可能达到数十万甚至百万的数量级。对于如此规模的文件数量，扫描文件系 统，生成文件列表就需要大量的时间，所以文件清理性能是此类人物不得不考虑的问题。
对于垃圾文件而言，有可能会是存放在特定目录下的文件，也有可能是是以特殊后缀名结尾的文件，还有可能是因为系统错误产生的 0 尺寸或者超大尺寸的文件，对于这些文件而言，文件数量一般不大，但是种类比较繁多，情况比较复杂，需要根据系统管理员的经验，制定比较细致的文件查询条 件，定期扫描，生成文件列表，然后进行进一步处理。
相关 Linux 命令简介
常用的文件系统管理命令包括 `ls`，`rm`，`find` 等等。鉴于这些命令都是常见的系统管理命令，在此不做赘述，详细用法请参见命令帮助或者 Linux 使用手册。由于大规模文件系统一般都存储在专用的文件系统上，这些文件系统都提供了独有的命令进行文件系统管理。本文实践章节以 IBM 的 GPFS 文件系统举例，以下简要介绍 GPFS 的若干文件系统管理命令。
- mmlsattr此命令主要用于查看 GPFS 文件系统中文件的扩展属性，如存储池信息，过期时间等属性。
- mmapplypolicyGPFS 采用策略对文件进行管理，此命令可以根据用户定义的策略文件，对 GPFS 文件系统执行各种操作，具有非常高的效率。
大批量文件自动清理的难点
Linux 文件删除机制
Linux 是通过 link 的数量来控制文件删除，只有当一个文件不存在任何 link 的时候，这个文件才会被删除。每个文件都有 2 个 link 计数器—— i_count 和 i_nlink。i_count 的意义是当前使用者的数量，i_nlink 的意义是介质连接的数量；或者可以理解为 i_count 是内存引用计数器，i_nlink 是硬盘引用计数器。再换句话说，当文件被某个进程引用时，i_count 就会增加；当创建文件的软连接或者硬连接的时候，i_nlink 就会增加。
对于 rm 而言，就是减少 i_nlink。这里就出现一个问题，如果一个文件正在被某个进程调用，而用户却执行 rm 操作把文件删除了，会出现什么结果呢？当用户执行 rm 操作后，ls 或者其他文件管理命令不再能够找到这个文件，但是进程却依然在继续正常执行，依然能够从文件中正确的读取内容。这是因为，`rm` 操作只是将 i_nlink 置为 0 了；由于文件被进程饮用的缘故，i_count 不为 0，所以系统没有真正删除这个文件。i_nlink 是文件删除的充分条件，而 i_count 才是文件删除的必要条件。
对于单个文件删除而言，我们可能完全不需要关心这个机制，但是对于大批量文件删除，这却是一个非常重要的因素，请允许我在随后章节中详细阐述，此处请先记下 Linux 的文件删除机制。
生成待删除列表
当一个文件夹下面有 10 个文件的时候，`ls` 可以一目了然，甚至可以用 `ls – alt` 查看所有文件的详细属性；当文件变成 100 个的时候，`ls` 可能只能看一看文件名了；文件数量上涨到 1000，多翻几页可能还能接受；如果是 10，000 呢？ `ls` 可能需要等上半天才能有结果；再扩展成 100，000 的时候，绝大多数系统可能都没有反应，或者“Argument list too long”了。不止是 `ls` 会遇到这样的问题，其它的常用 Linux 系统管理命令都会遇到类似的问题，Shell 有参数来限制命令的长度。就算我们可以通过修改 Shell 参数来扩展命令长度，但这并不能提高命令的执行效率。对一个超大规模的文件系统而言，等待 `ls` 和 `find` 等常用文件管理命令的返回的时间是不可接受的．
那么我们如何能够在更大数量级的文件系统上生成删除文件列表呢？一个高性能的文件系统索引是一个好方法，不过高性能的文件索引是少数人的专 利（这也解释了为什么 google 和 baidu 能这么赚钱）。好在如此规模的文件系统一般都只存在于高性能文件系统里面，这些文件系统都提供了非常强大的文件管理功能。譬如前面提到的 IBM 通用并行文件系统（GPFS）的 mmapplypolicy，通过直接扫描 inode 来快速扫描整个文件系统，并能够根据指定条件返回文件列表。下面演示如何根据时间戳和文件类型来获取文件列表
死锁对文件删除性能的影响
对于一个每天定时执行文件删除任务系统，首先生成待删除文件，然后把该列表作为输入执行删除操作；如果某天待删除列表特别大，导致第一天的删除任务还没有完成，第二天的删除任务就启动了，会有什么结果呢？
第一天还没有来得及被删除的文件会出现在第二天的删除文件列表中，然后第二天的文件删除进程会把它做为输出执行删除操作。此时，第一天的删 除进程和第二天的删除都会尝试去删除相同的文件，系统抛出大量的 unlink 失败的错误，删除性能会受到很大的影响。删除性能的下降，会导致第二天的文件依然没有被删除，第三天的删除进程会加剧删除文件的死锁，进入删除性能下降的 恶性循环。
如果简单的删除第一天生成的待删除列表，能够解决上述问题吗？不能。如前文所述的 Linux 文件删除机制，删除第一天的文件列表文件只能把该文件的 i_nlink 清零，当第一天的文件删除进程没有结束的时候，该文件的 i_count 就不为零，因而该文件不会被删除。直到该进程处理完列表中的所有文件，进程退出，第一天的待删除列表文件才真正被删除了。
我们至少需要在新的文件删除进程启动以前，把系统中其它的文件删除进程终止，才能保证不会发生删除死锁的情况。但是这样做，依然存在一些弊 端。考虑到极端情况下，如果连续一段时间删除进程都无法在一个周期内完成删除任务，那么待删除列表就会不断增长，文件扫描时间会延长，进而挤占文件删除进 程的工作时间，陷入另外一个恶性循环。
而且实战经验告诉我们，当删除列表特别巨大时，删除进程的工作性能也有所下降。而一个适当大小的参数输入文件，能够保证进程有效执行。所 以，按照固定尺寸将待删除列表文件分割成一系列文件，能够让删除操作稳定高效的执行。而且，在存储和主机性能允许的前提下，分割为多个文件还可以允许我们 并发执行多个删除进程
大批量文件自动清理的最佳实践
GPFS 文件系统下大规模额外年间自动清理的最佳实践
以下是在一个千万级的 GPFS 文件系统上进行的文件自动清理实践：硬件环境为两台 IBMx3650 服务器和存储容量为 50TB 的 DS4200 磁盘阵列，安装了 Linux 操作系统和 GPFS v3.2。目标是每天 2：00AM 执行文件清理操作，删除 30 天以前的文件和所有以 tmp 为结尾的文件。
mmapplypolicy 扫描结果显示该系统上有 323,784,950 个文件，158,696 个文件夹。
............. [I] Directories scan: 323784950 files, 158696 directories, 0 other objects, 0 skipped files and/or errors. .............
定义查找规则如下，保存为 trash_rule.txt
RULE EXTERNAL LIST trash_list EXEC RULE exp_scan_rule LIST trash_list FOR FILESET(data) WHERE DAYS(CURRENT_TIMESTAMP) – DAYS(ACCESS_TIME) > 30 RULE tmp_scan_rule LIST trash_list FOR FILESET(data) WHERE NAME LIKE %.tmp
执行 mmapplypolicy 并配合 grep 和 awk 命令生成待删除文件完整列表，再用 split 命令将完整列表分割为每个列表包含 10,000 个文件的子列表：
mmapplypolicy /data – P trash_rule.txt – L 3 | grep “/data” |awk ‘ {pint $1} ’ > trash.lst split – a 4 – C 10000 – d trash.lst trash_split_执行以下命令进行删除操作：
for a in `ls trash_splict_*` do rm `cat $a` done
将上述操作保存为 trash_clear.sh，然后定义 crontab 任务如下：
0 2 * * * /path/trash_clear.sh
手动执行删除任务，待删除文件扫描结果如下：
[I] GPFS Policy Decisions and File Choice Totals: Chose to migrate 0KB: 0 of 0 candidates; Chose to premigrate 0KB: 0 candidates; Already co-managed 0KB: 0 candidates; Chose to delete 0KB: 0 of 0 candidates; Chose to list 1543192KB: 1752274 of 1752274 candidates; 0KB of chosen data is illplaced or illreplicated;
在文件删除过程中，我们可以采用以下命令计算每分钟文件删除数量。从下面的输出可以得出，文件删除速度为 1546 文件每分钟：
df – i /data;sleep 60;df – i /data Filesystem Inodes IUsed IFree IUse% Mounted on /dev/data 2147483584 322465937 1825017647 16% /data Filesystem Inodes IUsed IFree IUse% Mounted on /dev/data 2147483584 322467483 1825016101 16% /data
通过 `time` 命令对文件删除操作进行计时，从输出结果可以看出，本次文件删除操作一共耗时 1168 分钟（19.5 小时）：
time trash_clear.sh real 1168m0.158s user 57m0.168s sys 2m0.056s
当然，对于 GPFS 文件系统而言，文件系统本身还提供了其他的文件清理方法，譬如可以通过 mmapplypolicy 来执行文件删除操作，通过这种方法，有可能实现更加高效的文件清理任务。本文的目的在于讨论一种通用的大规模文件清理方法，在此就不对基于文件系统所提供 功能的文件清理操作做进一步讨论了，感兴趣的读者可以尝试一下
from http://www.236z.com/html/30/29/35/2010/11/02/124895.html
0 条评论。