批量压缩文件实战：find与xargs高效协同指南

1. 一条命令跑不动了批量压缩的需求从哪来1.1 日志归档与文件转储最常见的批量压缩场景先说说我最初遇到这个需求的场景。当时有个临时搭建的数据分析环境跑了一批批数据同步任务每天在指定目录下生成几十到上百个大小不等的文本日志文件。日志滚动得很快一周下来磁盘空间开始告急运维要求把超过30天的日志全部压缩归档而后继续保留新文件。刚开始我是打算一条命令全部搞定结果发现根本没有那么简单——文件一多普通做法会在传参和中断风险上接连翻车。批量压缩这个任务看起来是“压缩几个文件”的简单组合一旦规模上来了就会变成一场对筛选、传参、压缩策略和资源控制的综合考验。当时的第一反应是用gzip因为它足够常见压缩速度和压缩率之间的平衡也合适。可问题是需要归档的日志文件分布在多层子目录里有些目录还需要特殊处理比如旧的中间结果目录要保留原始文件、不能直接打包或者某些临时目录根本不应该被纳入压缩范围。这类过滤逻辑用gzip单独处理需要写一大段脚本而find本身就是做筛选出名的配合xargs把筛选结果传递给压缩工具就成了最实用的组合拳。1.2 单条命令的瓶颈参数上限、串行等待、中断风险很多刚上手 Linux 的同学会问直接gzip 目录/*.log不就行了吗小规模确实可以但要注意两个硬伤。第一个硬伤是参数长度的上限。Linux 对命令行参数的总长度有明确限制可以通过getconf ARG_MAX查看。我机器上通常看到的是 2MB 左右但这里的长度计算不是按“文件个数”来算而是把所有参数的字节数加起来。如果你的文件名比较长日志目录又比较深超过了这个上限shell 会直接报Argument list too long命令压根不会执行。文件数量倒未必需要很多几千个长路径可能就把它撑爆了。第二个硬伤是串行等待和中断风险。如果用for循环一个个gzip逻辑上没错但效率很低而且一旦中途有文件损坏或者磁盘空间不足整个循环会中断压缩了一半的文件会散落一地后续还得手动检查哪些处理过了。当然循环脚本可以通过各种容错机制来改进但写起来就复杂了。真正合适的思路是分工find负责把所有符合条件的文件准确找出来xargs负责把这份名单分批、安全地交给压缩工具压缩工具则专注于自己最擅长的“把数据变小”这件事。这样每个环节都只做一件事出了问题也容易定位。1.3 组合拳的拆解思路find负责筛、xargs负责传、压缩工具负责压这套组合的核心是数据流而不是简单的“把三条命令拼接起来”。find的输出是一串路径这串路径可能包含空格、引号、甚至换行所以直接传给别的命令很危险。xargs的价值恰好在这里它能按照定长的规则分批读取输入以参数的方式把这批路径传递给目标命令还支持用-0选项处理以空字符分隔的输入从而安全解决文件名中特殊字符的问题。压缩工具在这条链路里的角色也值得琢磨。有的场景需要把多个文件打成一个包再压缩那就该用tar有的场景需要把每个文件单独压成.gz那就该用gzip还有的场景需要追求更高的压缩率可以换成xz。这三类需求find和xargs都能跟它们协作只是传递的粒度不同。整包场景要把文件“名单”传给tar逐个文件的场景要把路径一批批传给gzip按目录切包的场景则要先把目录名单筛出来再交给tar处理。理解了这个数据流你会发现在批量压缩这件事上方案不是写死的而是可以按文件特点、归档粒度、压缩率要求灵活组合的。2. find筛选文件的实战套路先选对再压缩2.1 按时间、大小、类型过滤的完整用法find是这批命令里最值得下功夫的一环因为压缩工具本身不关心哪些文件该压它只负责把你给它的路径处理完。筛选条件错了后面做得再快也是白做。按时间过滤是我在日志归档里最常用的。比如归档30天前的文件find /data/logs -type f -mtime 30这里-mtime 30表示文件的修改时间距今超过30天注意是“超过”也就是严格大于30天。如果你用的是-mtime 30那表示“正好 30 天前”这通常是写脚本时很常见的坑。想要更精确地控制到分钟可以改用-mmin例如-mmin 1440表示超过1440分钟没改过的文件。按大小过滤也经常用到。比如只压缩超过100MB的中间结果文件find /data/workspace -type f -size 100M-size的、-和裸数字含义很明确100M是大于100M-100M是小于100M100M则是精确等于。单位支持k、M、G等注意是小写的c表示字节。按类型过滤能避免把目录、软链接或设备文件拉进压缩任务里。写-type f就已经避免了大量麻烦。尤其是软链接gzip默认不跟随软链接但tar的行为又不同后面我会单独说。还可以组合多个条件。比如筛选出30天前、大于1MB、但排除某些后缀的普通文件find /data/logs -type f -mtime 30 -size 1M ! -name *.gz ! -name *.zip这行命令的含义是在/data/logs下找普通文件修改时间30天前体积大于1M名字不以.gz或.zip结尾。用!表示取反括号也能用来做逻辑分组不过要注意括号在 shell 里需要转义。2.2 排除目录与隐藏文件find的剪枝技巧有时筛选不仅要做加法还要做减法。假设你要压缩/data/project下的所有文件但希望跳过node_modules目录和.git目录因为那些目录又大又没有归档价值。直接在find里加-not -path可以但效率不高——find仍然会走进这些目录再把结果逐个过滤。更好的做法是使用-prune它在进入目录前就把它剪掉。find /data/project -type d \( -name node_modules -o -name .git \) -prune -o -type f -print说下这里的逻辑find从左到右处理表达式-prune的作用是“如果当前路径是目录且命中前面的条件就不要再往下走了”。完整写法里通常需要把-print放到最后单独写因为-prune -o -print的语义是“剪枝否则打印”。结果就是所有命中排除条件的目录都会被跳过其他文件正常输出。隐藏文件的处理也要看需求。默认find会把.开头的文件一起找出来有时候这正是你想要的比如.env文件需要一起归档。但也有时候你只想归档业务日志不想要这些隐藏配置。这时可以加上find /data/logs -type f ! -name .*不过要注意如果目录本身是隐藏目录-name .*只会匹配路径最后一段名字不会阻止find进入隐藏目录。想连隐藏目录一起跳过需要再用-prune配合处理。2.3 压缩前先跑一遍find用数量与体积确认结果这一步是我强烈建议保留的。批量压缩出问题往往不是因为压缩工具不行而是因为文件“名单”搞错了——要么压多了把不该归档的临时文件也塞了进去要么压少了漏掉了某些子目录。在真正执行压缩前先单独跑一次find把结果重定向到一个文本文件里然后做两件事。第一是看数量数数有多少行第二是看总体积用du估算这些文件合计占多少空间这能帮你在压缩开始前判断磁盘是否够用。find /data/logs -type f -mtime 30 /tmp/filelist.txt wc -l /tmp/filelist.txt tr \n \0 /tmp/filelist.txt | du --files0-from- -ch | tail -1这里的tr把换行转成空字符是为了配合du的--files0-from选项因为多行路径可能包含空格逐行传参并不可靠。先用这些命令确认“名单对不对、体量多大”再决定压缩用什么格式、并发度设多少比闷头直接执行要稳妥得多。3. xargs连接find与压缩工具的边界与陷阱3.1 一次传多少才合适-n与-L参数xargs的核心价值在于它能解决“参数列表过长”的问题它不会一次性把你给它的全部输入塞进命令而是分批处理。默认分批逻辑是按单条命令能接受的最大长度来估算的但有时候你希望自己控制每一批传多少参数或多少行。-n是最常用的控制参数。比如每5个文件一批交给gzipfind /data/logs -type f -mtime 30 -print0 | xargs -0 -n 5 gzip这会让xargs每积累5个路径就执行一次gzip直到全部处理完。为什么需要控制批量个数因为压缩工具本身也有内存和资源开销一次性传给gzip10000个文件它会尝试打开很多文件句柄容易触碰系统限制。-n可以调小一点让每批的任务量适中。另外还有-L参数它是按“行”来分批的适合处理每行是完整单条记录的输入。但注意-n是按参数个数-L是按行数两者行为不同。在find配合print0的场景下因为一行就是一条空字符结尾的记录用-n会更直观也更容易在出错时定位是哪一批失败了。有些朋友习惯用xargs -P做并行这个参数我放到后面性能调优里详细讲因为它和-n一起用时行为需要特别注意不是随便加个数字就行的。3.2 空格、换行、引号与通配符-0参数的核心价值这部分是xargs最容易被忽略也最容易翻车的地方。默认情况下xargs会在输入里把空格、制表符、空白字符全都当成参数分隔符同时还会识别单引号、双引号和反斜杠的转义规则。这在大部分简单场景下可以工作可一旦文件名里有空格默认行为就彻底乱了。比如目录下有一个文件叫report final.txt直接执行find /data/reports -type f | xargs gzip系统会把它当成两个参数report和final.txtgzip会找不到第一个文件同时把第二个文件错误地当作另一个目标处理。这种错误在你只看压缩结果时很难发现因为它可能只压了部分文件甚至压出了奇怪的空文件。解决办法是全程使用空字符作为分隔符。find -print0输出路径时每条路径后面跟的不是换行而是\0xargs -0则按\0来切分输入。因为文件名里几乎不可能出现空字符这种配对方式就是最严谨的find /data/reports -type f -print0 | xargs -0 gzip把-print0和-0配对使用值得作为固定习惯写进脚本不要因为当前目录下文件名看起来都很正常就偷懒。我遇到过不止一次某天有人把文件名改成了带空格或$的格式结果定时压缩脚本立刻开始报错。事前防御的成本远低于事后恢复。3.3 特殊场景find -print0配xargs -0的配对原则除了文件名的空格还要小心通配符。如果用xargs把路径传给tar而路径中包含*这类字符tar不会自己解析通配符但 shell 如果先展开了就变成了另一套逻辑。为了不让 shell 干预传参路径统一交给xargs命令行里不要额外加引号包住通配符更不要把未经过滤的路径直接拼进命令行。实际使用中find -print0 | xargs -0这个配对是最安全的。如果你想在xargs里执行带管道的命令注意管道符会被 shell 特殊处理因此通常需要在xargs命令里再开一个sh -c例如find /data/logs -type f -name *.log -print0 | xargs -0 -I {} sh -c gzip $1; echo $1 压缩完成 _ {}这里的-I {}会把每条输入替换到命令中的{}位置sh -c后面的第一个参数_是传给$0用的{}作为$1传入。这个写法在处理“每压缩一个文件就记录一笔日志”的需求时特别有用。但-I {}有个副作用它默认每一行输入就执行一次命令而且-n的设置会被忽略。所以大批量场景下用-I会明显放慢速度更适合小规模或者需要逐条处理的日志型任务。大文件批量压缩时直接传参给gzip然后并行处理效率显然更高。4. tar、gzip、xz与find/xargs的三种协同模式4.1 模式一整包归档压缩tar -T与tar -cf -配gzip第一种模式是把多个文件打成一个包再整体压缩成一个文件。这类需求最常见的是日志归档比如把7月所有的.log备份成一个backup.tar.gz。这里的重点已经不是单个文件了而是“整个集合”要作为一个整体保存。最稳妥的写法是用tar的文件列表输入能力而不是直接把find结果拼到命令后面find /data/logs -type f -mtime 30 -print0 /tmp/filelist0.txt tar --null -T /tmp/filelist0.txt -czf /data/archive/logs-$(date %Y%m%d).tar.gztar -T表示从文件读取要包含的路径列表--null与find -print0配对表示这里的列表是用空字符分隔的。这个小细节很关键如果你直接tar -T /tmp/filelist.txt而这个列表是用普通换行写的那么文件名里有换行时依然会出问题。还有另一种常见写法是直接让tar从find的输出流里读取无需中间文件find /data/logs -type f -mtime 30 -print0 | tar --null -T - -czf /data/archive/logs.tar.gz注意这里的-T --表示从标准输入读取列表。这个命令把find、tar、gzip完全串在了一条管道里中间不需要落地临时文件也不会留下中间产物。实测下来在文件数量很大的场景这个方案明显比find ... | xargs tar更省心因为tar天然支持从列表构建归档不会遇到重名文件互相覆盖的问题。4.2 模式二逐个文件压缩find -exec vs xargs第二种模式是希望每个文件单独保留一个.gz文件而不是打成一个包。典型场景是业务日志需要被某个平台持续读取平台可直接解压单个日志不支持打开一个大 tar 包。逐个压缩的命令可以这样写find /data/logs -type f -name *.log -mtime 30 -print0 | xargs -0 -n 10 gzip每个.log文件会被压缩成.log.gz原始文件被替代。注意gzip默认压缩成功后会删除原始文件想保留原文件就加-kfind /data/logs -type f -name *.log -mtime 30 -print0 | xargs -0 -n 10 gzip -k有人会问这里为什么不用find -exec gzip {} \;当然也可以用但两者有区别。-exec ... \;是找到一个文件就执行一次命令启动进程的开销很大文件数量多时会明显慢-exec ... 则是把找到的文件累积成一批再执行效率高了不少但它在内部会把命令行构造好如果文件数量极多它也会自己处理分批逻辑与xargs非常相似。实际上find -exec ... 在大多数场景下和xargs可以互换。我倾向于使用xargs原因是它能同时配合-P做并行对压缩这类 CPU 密集任务提升明显而find -exec在这方面相对受限。如果你不想多记一个命令用-exec ... 也完全没问题只是对于并行控制来说xargs更灵活。4.3 模式三按时间切片、按目录打包第三种模式是按时间或目录粒度分别打包而不是一刀切。比如日志目录/data/logs下每天有一个子目录2025/01/15/你想按“天”打包把每一天的数据单独变成一个tar.gz。按目录打包的写法可以这样find /data/logs -mindepth 1 -maxdepth 1 -type d -print0 | xargs -0 -n 1 -I {} tar -czf {}.tar.gz -C /data/logs {}仔细看这里的-C /data/logs它的作用是切换工作目录这样打出来的包内部路径不会带着完整前缀解压时目录结构干净很多。-I {}的缺点前面提过它会逐条执行目录数量通常不会成千上万所以性能不是问题。还有一种更灵活的按时间切片方式先用find按文件名里的日期筛选再按日期分组传给tar。这个需求用find表达式可以做到也可以依赖xargs -L按固定行数切分。例如每个包只打2000个文件find /data/logs -type f -name *.log -print0 | xargs -0 -n 2000 tar -czf archive.tar.gz但这个写法有个隐藏问题同一批任务会生成同名archive.tar.gz后面的会覆盖前面的。所以我通常会把数量信息带进名称里。具体做法是给打包命令加sh -c让每个包文件名中带上批号find /data/logs -type f -name *.log -print0 | xargs -0 -n 2000 sh -c tar -czf archive-$(basename $(dirname $0)).tar.gz $ /dev/null这么写有点绕说明一下sh -c后面的/dev/null相当于$0find传来的路径都变成$文件名里用计数变量就得靠额外计数器了。实际上更稳妥的做法是自己在脚本里维护一个计数器或者直接用awk把filelist按2000行分割后循环处理。虽然命令看起来不简单但“按批产出一批独立的压缩包”这个需求本身就值得花点心思。4.4 压缩格式怎么选gzip vs bzip2 vs xz vs zstd压缩工具的选择直接决定了“压缩率”和“压缩时间”的取舍。下面是我在归档任务里常用的对比参考工具压缩率压缩速度解压速度适用场景gzip中快快日常日志归档、传输最通用bzip2较高慢中不常用压缩率要求较高且不赶时间xz最高慢中追求极限压缩率、归档长期保存zstd可调很快很快需要频繁压缩/解压、大数据量场景实际项目里我默认选gzip因为几乎所有 Linux 环境都支持tar直接内置-z选项不用额外装工具。当磁盘真的很紧张、归档文件又不常被读取时我会选xz例如把半年以上的冷数据归档成.tar.xz能够显著节省空间代价是压缩时间可能要长几倍。如果你在意的不是压缩包体积而是压缩效率zstd是个很好选择。它的压缩等级可以从-1到-19调节默认等级下速度比gzip快很多压缩率也不差。不过注意zstd不是所有生产环境都预装的需要先确认目标机器上有没有zstd可执行文件否则定时任务跑到一半才会报错。bzip2则处在一个比较尴尬的位置压缩率优于gzip但显著慢于xz和zstd在多数场景下我都不优先选它。除非有遗留脚本要求生成.bz2文件或者上游系统只认这个格式否则可以跳过。5. 并行压缩与性能调优CPU与IO的平衡5.1 并行压缩工具pigz、pbzip2、pxz与zstd压缩是 CPU 密集型操作单核压缩一个很大的文件可能要很久尤其是xz。现代服务器通常有好几个物理核心但标准的gzip、bzip2、xz都默认只使用单线程这样就浪费了好几个空转的核心。并行压缩工具就是来解决这个问题的。最常用的替代品是pigzparallel gzip它可以指定用几个线程来压缩例如4线程find /data/logs -type f -name *.log -print0 | xargs -0 -n 1 -P 4 pigz这里-P 4是xargs同时启动4个进程-n 1让每个进程只处理一个文件。假如不指定-Pxargs默认是串行的那么写不写pigz都只会在一个核上跑。pbzip2和pxz分别是bzip2和xz的并行版本用法与pigz相似。zstd就更方便了它原生就支持多线程通过-T指定线程数find /data/logs -type f -name *.log -print0 | xargs -0 -n 1 zstd -T4值得注意的是这种方式对“多个文件同时并行压缩”有效单文件分块并行压缩又有所不同。pigz既能多进程分别压不同文件也能在压单个大文件时用多线程。对于批量日志场景我更推荐先按文件粒度并行因为不同文件之间互不依赖适合用xargs -P控制整体并发度。5.2 控制并发数与进程优先级并行虽好但也要小心别把机器压垮。如果压缩任务启动时没有控制并发数2000个日志文件会被同时拉起来2000个压缩进程CPU瞬间被打满SSD的 IO 也可能被拖垮。生产服务器上出现这种状况比压缩速度慢还要危险。控制并发数最简单的是用xargs -Pfind /data/logs -type f -name *.log -print0 | xargs -0 -n 1 -P 8 gzip这里的-P 8表示始终最多同时跑8个gzip进程。我一般建议先用nproc看看机器有多少逻辑核心把-P设为nproc的一半或者四分之三留一点资源给其他服务。对于 IO 密集的服务器压缩进程数量甚至可以更低。除了xargs -P还可以在命令行前面用nice或ionice降低任务优先级。举例find /data/logs -type f -name *.log -print0 | xargs -0 -n 1 -P 8 nice -n 10 gzipnice -n 10会让压缩进程让出更多 CPU 时间片。ionice -c 2 -n 7则可以把块设备读写优先级调低避免压缩任务和线上业务抢磁盘 IO。我建议在夜间大批量归档任务里同时加上这两个参数白天跑的话尤其需要控制优先级。5.3 压缩完如何验证完整性压完不等于万事大吉。归档任务最怕的是压出来的文件损坏尤其是如果这些压缩包要传给别处的系统校验会非常重要。我自己的习惯是压缩完成后立即做一轮列表验证确认归档包内文件数量和find找出来的数量一致。一个相对完整的流程可以这样写cnt_before$(find /data/logs -type f -name *.log -mtime 30 | wc -l) find /data/logs -type f -name *.log -mtime 30 -print0 | xargs -0 -n 1 gzip cnt_after$(find /data/logs -type f -name *.log.gz -mtime 30 | wc -l) echo 压缩前: $cnt_before, 压缩后: $cnt_after如果两边数字一致基本可以确定没有遗漏文件。如果还需要更严格的完整性校验建议对单个压缩包做哈希记录比如find /data/logs -type f -name *.gz -print0 | xargs -0 md5sum /data/archive/hashes.md5之后再结合md5sum -c就能快速验证压缩包是否完整。对超大压缩包gzip -t可以测试压缩包完整性但它只能验证包内数据是否能被正确解压无法验证它是否就是你想要的那批文件。所以“数量匹配”和“哈希匹配”这两件事建议都做落地的保障才更充分。6. 实战踩坑记录批量压缩最容易翻车的六个场景6.1 参数列表过长Argument list too long这个错误是最经典的批量压缩翻车现场。文件数量不算多路径也不算太长但几千个文件还是触发了命令行长度上限。用gzip /data/logs/*.log这类写法最容易碰到因为 shell 会先把所有文件名展开再传入命令一旦总长度超出ARG_MAX就报错。解决方式就是不要用 shell 通配符让find通过流的方式把路径传出来find /data/logs -type f -name *.log -print0 | xargs -0 gzip此时路径不经过命令行拼接而是由xargs分批传给gzip绕过了参数长度上限。这个思路适用于一切“文件很多、路径很长”的场景。6.2 文件名带空格、中文与换行的处理文件名带空格的问题我前面用-print0和-0解决了。中文文件名在find输出里通常没太大问题关键是终端本身的编码和tar的 locale 设置。如果locale不对tar解包时可能出现乱码。建议在脚本里先确认LANGexport LANGC.UTF-8换行出现在文件名里的情况更少见但确实存在。只要路径里有\n普通按行读取的方式就会崩溃。必须全程用-print0-0避免任何按行分割的操作。6.3 软链接与硬链接的坑find -type f默认会匹配普通文件和“指向普通文件的符号链接”吗实际上-type f对符号链接是否有效取决于是否加了-L或-P选项。未加时-type f不匹配符号链接本身。因此如果目录里有个current.log - access.log.20250115你想压缩它反而可能漏掉。tar对软链接的处理同样要注意。默认情况下tar归档符号链接时归档的是链接本身不是链接指向的文件内容。如果直接tar -czf backup.tar.gz /data/logs日志目录里的软链接在恢复时就只是个链接。如果希望跟随链接并把实际文件内容也打进去用tar -htar -czhf backup.tar.gz -T /tmp/filelist.txt这里补一句如果压缩任务的目标是“把目录整体打包备份”通常跟随符号链接更完整如果目标只是“把日志文件归档、保留其链接关系”保留链接也能节省空间。使用前想清楚这层差别就能正确选择参数。6.4 正在写入的文件被压缩日志系统是持续运行的某个文件可能在你启动压缩任务时还在被追加写入。直接对它运行gzip会得到的是一个压缩时的快照后面新产生的日志仍然会往原文件路径写入但这个路径已经被改名了导致日志系统只能重新创建文件或者某些程序会因为文件句柄错乱而产生错误。对于这个问题我习惯在压缩前先判断文件是否仍在更新。用find -mmin避免压过于“新鲜”的文件find /data/logs -type f -name *.log -mmin 10 -print0 | xargs -0 -n 1 gzip这样最近10分钟内被修改的文件会被跳过给日志写入进程一个缓冲窗口。如果因为业务原因必须立刻归档那就需要先通知服务切换日志输出或者在压缩前短暂停写。6.5 磁盘空间不足导致压缩中断压缩过程中临时文件可能占用空间尤其用tar打包时.tar.gz会边写边占磁盘。如果磁盘快满了压缩到一半会报No space left on device而已经写进去的部分可能不完整。建议做法是压缩前先算好空间余量。用df -h看目标卷可用空间再用du -sh估算要归档文件的总大小。注意单个.tar.gz能小很多但它压缩过程中tar边读边写并不会同时把整个包放到内存里但中间文件本身就会在同一目录下不断增长。另一个常见习惯是先在一个有足够空间的目录生成压缩包再移动过去这样能避免目标目录空间不足的问题。6.6 tar包跨平台兼容性问题tar格式总体上是跨平台的但不同版本的tar对长路径、ACL、稀疏文件的支持有差异。比如 GNU tar 和 BSD tar 的参数就有一部分不同。如果压缩包是要发给 macOS 或 BSD 系统处理的你在 Linux 上用 GNU tar 打出来的包含特殊扩展头的包可能在对方环境里解压出警告。没有两个系统都跑过的环境时尽量用基础参数tar --formatustar -czf backup.tar.gz -T /tmp/filelist.txtustar是兼容性较好的老格式能避免部分新扩展头的问题。当然ustar对超大文件、超长路径的支持有限如果你要归档的都是几百GB的大文件还是要用默认的格式。跨平台文件传输后一定要先在目标机器上试解压一个测试包再批量正式解压。最后再分享两个小经验批量压缩这项工作真正决定可靠性的往往不是命令本身而是你在执行前有没有做足“名单验证”和“空间估算”。我自己的固定流程是先用find把名单列出来看一眼数量和体积再决定压缩格式和并发度压缩过程中记录开始和结束时间结束后立刻比对文件数量对特别重要的归档再补一次md5sum校验。看起来多花了几分钟但能省下事后排查的几小时。如果在你的场景里文件数量经常超过几十万或者单文件达到GB级建议单独写一个带日志、带锁、带中断恢复的脚本而不是直接在命令行里敲一条长管道。脚本里可以用trap捕获中断信号在退出前把已经处理过的文件记录到一个状态文件中下次运行时跳过它。这是批量压缩真正进阶的方向但那是另一个更复杂的话题了。先从find、xargs与压缩工具的协同入手把基础这几条命令练熟日常的日志归档和文件转储任务已经能处理得非常漂亮。