Linux下如何快速删除大量碎小的文件？

快来打我* 2023-02-23 09:00 1阅读 0赞

XX系统，通过FTP给客户实时传送文件，正常逻辑是客户收到文件后，自动删除FTP服务器上的本地文件，但经常出现文件已经推送了，客户没删除文件的情况。每个文件其实是很小的，可能几K，但是量很大，1天几万个，以至于时间久了，本地积的文件就会很多。我们不说让客户怎么排查问题，单就这个现象，如果积了几百万的小文件，我们能做些什么？你可能会说，删了啊，确实应该删了，但是小文件多了，会产生什么影响？如果直接rm，你认为行么？

颜总这篇小文，就是介绍了针对这种情况的操作，《[Linux如何快速删除大量碎小文件？][Linux]》，受益匪浅。

Linux文件系统容量分为大小容量和inode容量，前者限制大小，后者限制数量。

> 使用df -h，查看大小容量使用情况。  
> 使用df -i，查看inode容量使用情。

当我们遇到文件系统容量爆满，首先快速定位，

1. 寻找指定目录最大文件

du -a /data |sort -nr|head -n 10

2. 统计指定目录下文件数

ls -Rf1 /data |grep '^-' |wc -l

举个例子，某系统巡检中发现inode空间爆满(df -ih)，

/dev/mapper/red-root 550G 550G 20K 100% /

通常，监控工具只关注大小容量空间使用情况，很少关注inode空间。

根据上边命令(2)定位到问题目录，在该目录下执行ls报错如下，

ls: memory exhausted

很显然，在问题目录ls命令已经无法将所有文件列出来。因为ls默认会对文件按首字母排序，而排序过程需要消耗内存，文件非常多的时候，对内存的消耗是非常恐怖的。

这该怎么办？此时，可以使用-f1参数，这样就不排序，将文件列表输入到临时文件中。

ls -f1 ./* > ~/clear.log

输出完文件后，产生一个5G的文件，

-rw-r--r-- 1 oradba oinstall 5533944289 Jan 10 14:53 clear.log

可见该目录下文件极多，wc -l clear.log统计，得到文件数约2亿。

由于文件过大，无法查看并使用，如下使用split命令将该文件切分成每一个500Mb。

split -b 500M clear.log -d -a 3 clear.log

注：-b按照大小切分， -n按照制定行数切分。

分割后：

![format_png][]

编写脚本，按照文件批量删除，

[root@localhost ~]$ cat clear.sh
    #!/bin/bash
    for i in `cat clear000`
    do
    rm -rf ./$i
    done
    echo "complete!"

替换脚本中clear000依次将所有文件删除，完成清理工作。

另一种方案，

ls -f1 ./* | head -n 1000 | xargs rm -f

说到这里，可能有同学会说，为什么不在问题目录下rm -rf ./\* 呢？

这里提一下./\*的工作原理，他将目录下所有文件名串接到rm -rf后边。像这样：

rm -rf a b c d e f ...

如上，这是一条shell指令。不幸的是无论unix，还是linux，都对单条命令长度有最大限制。

> AIX操作系统受参数ARG\_MAX的限制，getconf arg\_max查询。  
> Linux操作系统受参数LINE\_MAX的限制，getconf line\_max查询。

这就是文件太多的时候，为什么rm -rf ./\*会报错的缘故。  
  
归根结底，这个问题的最佳解决方式就是让客户确认文件删除逻辑，一旦不能搞定，就进行文件容量和大小的监控，超过某个阈值，则移动文件进行压缩备份或者直接删除，避免本机影响。

**近期的热文：**

《[YNWA，同样是我们普通人的鞭策][YNWA]》

《[小白是怎么搞懂GC全过程？][GC]》

《[Gdevops峰会：一起探讨国产分布式数据库的选型与应用][Gdevops]》

《[海底的下面究竟有什么？][Link 1]》

《[几种去重的SQL写法][SQL]》

《[打造国产技术产品的必要性][Link 2]》

《[SQL查询总是先执行SELECT语句么？][SQL_SELECT]》

《[Oracle删除字段的方式和风险，你都了解么？][Oracle]》

《[最烧脑的珠峰高程测算过程][Link 3]》

《[了解阿克曼转向原理的作用][Link 4]》

《[登录缓慢的诡异问题][Link 5]》

《[不可不知的7个JDK命令][7_JDK]》

《[一个Full GC次数过多导致系统CPU 100%的案例排查][Full GC_CPU 100]》

《[Java GC的基础知识][Java GC]》

《[Linux下的^M困惑][Linux_M]》

《[Oracle相关提问的智慧技巧][Oracle 1]》

《[很久以前的一篇对初学Oracle建议的文章][Oracle 2]》

《[PLSQL Developer几个可能的隐患][PLSQL Developer]》

《[从70万字SRE神作提炼出的7千字精华文章][70_SRE_7]》

《[从数据误删到全量恢复的惊险记录][Link 6]》  
《[公众号600篇文章分类和索引][600]》

[Linux]: http://mp.weixin.qq.com/s?__biz=MzIyMTkwMzQ2OA%3D%3D&chksm=e834ee2edf436738c7ce401846ea46091b001c16d3701d2d4d41b2a7aae92da92cba953f5418&idx=1&mid=2247483693&scene=21&sn=e0fa33a3951b7cdd1019fc47e3af3a7e#wechat_redirect
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy84Q1k0RjF6Y3M3aWJwNHlwN1VMWTBCRkpjbnF0cWRjSE9JU1ZieTdKV2F2eWJCTUZHNnNpY0k4eWdmQzJIaGFlbTh3S2tZSFBsemR3c2xHd3llZGliZ1R4US82NDA?x-oss-process=image/format,png
[YNWA]: https://blog.csdn.net/bisal/article/details/107010917
[GC]: https://blog.csdn.net/bisal/article/details/106846249
[Gdevops]: https://blog.csdn.net/bisal/article/details/106821414
[Link 1]: https://blog.csdn.net/bisal/article/details/106654180
[SQL]: https://blog.csdn.net/bisal/article/details/106631874
[Link 2]: https://blog.csdn.net/bisal/article/details/106512908
[SQL_SELECT]: https://blog.csdn.net/bisal/article/details/106416527
[Oracle]: https://blog.csdn.net/bisal/article/details/106345687
[Link 3]: https://blog.csdn.net/bisal/article/details/106293626
[Link 4]: https://blog.csdn.net/bisal/article/details/106232934
[Link 5]: https://blog.csdn.net/bisal/article/details/106204880
[7_JDK]: https://blog.csdn.net/bisal/article/details/106132095
[Full GC_CPU 100]: https://blog.csdn.net/bisal/article/details/106110289
[Java GC]: https://blog.csdn.net/bisal/article/details/106066216
[Linux_M]: https://blog.csdn.net/bisal/article/details/106030314
[Oracle 1]: https://blog.csdn.net/bisal/article/details/106009871
[Oracle 2]: https://blog.csdn.net/bisal/article/details/105963320
[PLSQL Developer]: https://blog.csdn.net/bisal/article/details/105803468
[70_SRE_7]: https://blog.csdn.net/bisal/article/details/105742900
[Link 6]: https://blog.csdn.net/bisal/article/details/105697127
[600]: https://blog.csdn.net/bisal/article/details/104548761