在日常 Linux 运维中重复数据占用磁盘空间的问题非常常见备份目录里多个时间点的同一份文件、测试环境复制出来的一批虚拟机镜像、容器镜像层、日志归档包都会让同一份内容以多个副本的形式占用成倍空间。Oans 是一个面向 btrfs 和 XFS 文件系统的快速去重deduplication工具它的核心思路不是把文件内容搬来搬去而是借助文件系统原生的 reflink 和 FIDEDUPERANGE ioctl让内核把相同的数据块合并成共享的 extent。这篇文章会围绕 Oans 这条主线讲清楚文件系统级去重的原理、使用前的环境检查、最小操作流程、结果验证方式以及生产环境里最容易踩的坑。由于 Oans 属于 Show HN 类型的源码项目版本迭代可能很快不同版本的命令参数和输出格式不一定完全一致。因此正文里出现的命令主要用于说明去重工具的标准操作链路落地前请以 Oans 仓库的 README 和--help输出为准。真正要掌握的是扫描、预览、执行、验证这四个阶段背后的判断方法。1. 先理解 Oans 做去重时文件系统在底层做了什么1.1 去重解决的不是“删除文件”而是“合并数据块”很多人第一次接触去重时会误以为去重等于“把重复文件删除一份”。实际上文件系统级去重比删除文件安全得多也灵活得多。两个文件内容完全相同时它们在文件系统里通常各自拥有一段独立的物理磁盘块。用户看到的是两个文件名底层则是两份互不相干的 64 MiB 数据。去重要做的事情是把这两个文件在逻辑上保留原样但让它们的文件内容映射到同一组物理磁盘块。这样这两个文件仍然可以独立修改、独立删除只是在修改之前共享同一份数据。这种能力依赖文件系统的 CoWCopy-on-Write和 reflink 机制。日常生产环境里常见的cp --reflinkauto就是同一类机制复制大文件时如果文件系统支持 reflink内核不会真实复制数据块而是让新文件先共享旧文件的 extent等到某个文件真正写入新内容时才会复制被修改的数据块。Oans 做的事情和cp --reflink正好是反过来的方向cp --reflink从创建副本时就开始共享Oans 则是在大量普通副本已经存在之后扫描发现内容相同的块再把它们合并成共享 extent。1.2 FIDEDUPERANGE 是 Oans 的关键入口用户空间程序不能直接操作文件系统的 extent 映射Oans 最终要通过 Linux 内核提供的FIDEDUPERANGEioctl 完成合并。这个 ioctl 的调用流程可以简单理解为打开两个文件得到两个文件描述符。告诉内核比较文件 A 的某个范围和文件 B 的某个范围。内核先实际读取并比较这段范围内的字节内容。如果内容完全一致内核把文件 B 对应范围的 extent 修改为文件 A 的共享 extent。系统调用返回结果用户空间程序处理每个范围的status字段。这里有一个很容易被忽略的关键点FIDEDUPERANGE不是靠用户空间传哈希值来信任的而是由内核重新按字节比较。也就是说即使扫描阶段出现了误判最终真正执行时内核还会再做一次内容校验只有完全一致的数据块才会被合并。另一个限制是参与去重的两个文件必须位于同一个文件系统、同一个挂载点内。复制文件到另一块磁盘再执行去重是不可能走通这个 ioctl 的。1.3 btrfs 和 XFS 去重能力差异Oans 把 btrfs 和 XFS 并列支持并不是因为它们实现机制相同而是这两个文件系统都具备 reflink 能力也都暴露了FIDEDUPERANGE接口。实际使用时两者的差异会影响操作前的检查方式。维度btrfsXFSreflink 支持原生支持CoW 设计需要内核 4.5文件系统格式化时开启 reflink 特性默认状态大多数发行版挂载后即可使用新版mkfs.xfs默认开启 reflink老系统或老磁盘可能未开启适用场景快照多、大量小文件、需要灵活管理子卷大型文件、备份存储、虚拟化镜像目录元数据压力共享 extent 多时元数据占用会增加相对稳定但 reflink 会产生额外 btree 元数据常见问题碎片增长、metadata 占用老文件系统需要重新格式化才能开启 reflink生产环境做选型时不要只看“能不能去重”还要评估这个文件系统上是否已经存在大量快照、是否长期跑高并发写入、磁盘碎片是否已经比较严重。去重能节省空间但会额外增加文件系统元数据操作这两者需要权衡。2. 环境准备先确认内核、文件系统和挂载选项2.1 内核版本和文件系统类型检查执行任何去重操作之前先确认目标目录所在的文件系统类型和内核版本。很多“去重工具没有生效”的问题根源不在工具本身而在环境和挂载参数。uname -r findmnt -no FSTYPE,OPTIONS /datauname -r输出版本号。对 XFS 来说内核 4.5 以上才相对可靠。findmnt -no FSTYPE,OPTIONS /data会输出/data所在文件系统类型和挂载选项。如果文件系统类型不是 btrfs 或 XFS那么 Oans 这类工具大概率无法工作因为底层依赖的FIDEDUPERANGE只在这些文件系统上有完整支持。2.2 确认 reflink 能力XFS 比较特殊。较新版本的mkfs.xfs默认开启 reflink 特性但老文件系统可能是在没有该特性时格式化的。格式化后reflink 特性不能像普通挂载选项一样随时开启只能重新格式化或迁移数据。xfs_info /data | grep reflink如果输出是reflink1说明该文件系统在格式化时已经启用 reflink。如果输出是reflink0那么去重工具调用FIDEDUPERANGE时大概率会失败。btrfs 的检查相对简单btrfs filesystem show /databtrfs 从很早的内核版本就支持 reflink 和 CoW只要文件系统正常挂载通常可以直接使用去重功能。注意如果xfs_info显示 reflink 未开启不要尝试在生产磁盘上直接修改格式化参数。正确做法是备份数据、重新格式化并开启 reflink再恢复数据。否则数据安全风险极高。2.3 构建 Oans 的必要依赖Oans 如果是源码项目构建时通常需要系统具备 C 编译环境gcc、make、内核头文件、基础工具链。不同版本依赖可能不同建议先查看项目 README 中列出的依赖清单。# 源码项目的常见构建方式具体以 Oans 仓库说明为准 git clone project-repo oans cd oans make sudo make install如果环境里有发行版打包好的二进制或软件包优先使用打包版本升级和卸载都会省事很多。源码构建时不要跳过测试步骤有make test之类命令时先跑一遍。还要注意运行权限。执行FIDEDUPERANGE时运行用户需要对参与去重的文件具备读权限。普通用户可以先在自己目录下的小范围测试目录里验证确认工具行为符合预期后再让有权限的运维人员在生产目录执行。3. 最小可复现流程从准备测试数据到完成去重3.1 创建测试目录和重复数据先准备一个隔离的测试目录避免在真实数据目录上直接测试。这里用dd生成随机内容再用cp复制出多个完全相同的大文件模拟最常见的重复场景。sudo mkdir -p /data/dedup-test sudo chown $USER /data/dedup-test cd /data/dedup-test dd if/dev/urandom ofbase.bin bs1M count64 statusprogress cp base.bin copy1.bin cp base.bin copy2.bin dd if/dev/urandom ofpiece.bin bs1K count16 cp piece.bin piece-a.bin cp piece.bin piece-b.bin sync这里使用/dev/urandom生成随机内容是为了避免产生稀疏文件。如果内容全为 0文件系统可能用空洞优化干扰去重效果观察。测试完成后可以对比去重前后各文件的哈希值确认内容没有变化。3.2 查看工具帮助确认命令参数不同去重工具的命令风格差异很大有的使用子命令如scan、dedupe有的直接通过参数控制 dry-run 模式。首次使用 Oans 时先查看帮助输出。oans --help# 示例输出不同版本参数名可能不同 Usage: oans [OPTIONS] path --block-size dedupe block size --dry-run show what would be deduplicated --threads parallel worker threads --min-size ignore files smaller than this size如果帮助输出与上面的示例不一致以实际输出为准。核心要确认的是当前版本是否支持预览模式、如何指定块大小、如何控制并发、如何查看统计结果。3.3 先做预览模式确认候选重复范围去重的第一步永远不是直接执行而是扫描和预览。用 dry-run 模式跑一遍工具会遍历文件、分块、计算哈希、把相同哈希的块作为候选集合。oans /data/dedup-test --dry-run# 示例输出用于说明统计维度的含义 Scanned files: 6 Total data: 136 MiB Candidate duplicates: 128 MiB Extents to dedupe: 3 groups这个阶段不会修改任何文件只是生成统计。正常情况下base.bin、copy1.bin、copy2.bin应该被识别为高度重复piece-a.bin和piece-b.bin也会进入候选集合。3.4 执行去重确认预览结果符合预期后再正式执行。oans /data/dedup-test --apply如果版本使用子命令风格可能是oans dedupe /data/dedup-test执行过程会看到类似下面的进度信息[1/3] deduplicating base.bin - copy1.bin: OK [2/3] deduplicating base.bin - copy2.bin: OK [3/3] deduplicating piece.bin - piece-a.bin: OK到这里Oans 已经调用内核把相同的 extent 合并。下一步是验证而不是急着看空间节省了多少。注意dry-run 输出显示的重复量只是“候选”。真正合并时内核还会逐字节比较所以最终节省的空间可能比预览统计小这是正常现象。4. 关键参数背后的取舍块大小、并发、安全模式4.1 块大小决定命中率和系统开销块大小是去重工具最重要的参数。块越大单次FIDEDUPERANGE需要比较的字节越多哈希计算次数和 ioctl 调用次数越少块越小越容易发现文件内部的重复片段但索引、哈希和系统调用的开销会显著上升。块大小适用场景优点缺点64K - 128K混合目录、普通文件小范围重复也能发现索引大、哈希多、metadata 压力高512K - 1M备份包、镜像、日志平衡开销与命中率小文件内重复可能漏掉4M 及以上大型虚拟磁盘、ISO 镜像ioctl 次数少、速度快小文件重复几乎无法发现选择块大小时可以先用默认值跑 dry-run再对同一目录用更大或更小的块对比候选重复量。不要一次性在大目录上反复测试先用一个代表性子目录采样。如果 Oans 支持参数调整示例oans /data/dedup-test --block-size 1M --dry-run4.2 扫描范围、最小文件大小和排除规则去重工具默认扫描目录下所有普通文件但某些文件不应该参与去重小于一个块大小的文件通常无法通过块对齐产生可合并 extent建议直接跳过。正在被写入的日志文件去重过程中内容不断变化既降低命中率也可能造成重复 ioctl 调用。socket、FIFO、设备文件不是普通文件不应进入扫描范围。跨挂载点的路径不同文件系统之间的文件不能合并。如果 Oans 支持--min-size参数可以根据文件大小过滤oans /data/dedup-test --min-size 1M --dry-run配合--dry-run可以快速估算只有大文件重复量足够高才值得投入去重。4.3 并发和 I/O 控制去重过程中文件系统既要读文件内容计算哈希又要执行 ioctl 修改 extent 映射。高并发可以提高扫描速度但也会带来明显的 CPU 和 I/O 压力。生产环境中建议把去重安排在低峰期并用系统工具降低进程优先级。ionice -c 3 nice -n 19 oans /data/backup --applyionice -c 3表示 idle 级别让去重进程只在磁盘空闲时读写。nice -n 19降低 CPU 调度优先级。配合--threads参数把并发控制在合理范围。如果磁盘是机械硬盘并发过高会导致磁头反复移动整体吞吐反而下降。如果是 SSD关注写入放大和元数据压力即可。4.4 为什么很多去重工具默认先做 dry-run去重不会修改文件内容但会修改文件系统的 extent 映射。这个操作不像删除文件那样可以回收站恢复也不像普通复制那样有明确的“反操作”。一旦大量文件共享 extent后续其中任何一个文件发生写入都可能触发 CoW 复制产生新的数据块。因此先通过 dry-run 查看候选重复量再人工判断是否执行是去重操作的正确姿势。即使 Oans 支持一键执行也应该在自己的流程里强制加入“预览确认”这一步。5. 验证结果空间、数据完整性和 extent 共享5.1 空间统计执行完去重后不要只用du -sh判断结果。不同版本的du对 reflink 共享 extent 的统计口径不一样较新的 coreutils 会尽量按实际分配空间计算但仍以df看到的文件系统级别变化为准。df -h /data du -sh /data/dedup-test执行前先记录一次基线值执行后再对比这样最直观。如果文件系统是 btrfs还可以用 btrfs 自带的统计命令btrfs filesystem du --summarize /data/dedup-testType Size Used Referenced Data 136MiB 8MiB 136MiBUsed是实际分配空间Referenced是逻辑引用大小。两者差距越大说明共享 extent 越多去重效果越好。5.2 查看 extent 是否真的合并空间统计只能说明整体情况如果需要确认具体文件的 extent 是否共享可以使用filefrag。filefrag -v /data/dedup-test/copy1.binFilesystem type is: 9123683e File size of /data/dedup-test/copy1.bin is 67108864 (16384 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: flags 0: 0.. 16383: 123456.. 139839: 16384: eof如果base.bin、copy1.bin、copy2.bin的物理偏移范围出现重叠说明它们共享了同一段物理磁盘块去重确实生效。XFS 环境下也可以用xfs_io -r -c fiemap查看物理映射。5.3 内容完整性验证去重后最重要的验证是确保文件内容没有变化。这里不能只看文件名必须对每个文件计算哈希并用cmp对比原始文件与副本的字节内容。sha256sum /data/dedup-test/* cmp /data/dedup-test/base.bin /data/dedup-test/copy1.bin cmp /data/dedup-test/base.bin /data/dedup-test/copy2.bin去重前后这些文件的哈希值必须完全一致。如果哈希不一致说明执行过程中出现了严重问题应立即停止后续目录的去重并检查文件系统状态。6. 常见问题排查6.1 提示 FIDEDUPERANGE 不支持问题现象常见原因检查方式处理建议工具报 ioctl not supported文件系统不是 btrfs/XFSfindmnt -no FSTYPE /data确认目标目录所在文件系统XFS 上报 reflink 相关错误XFS 在格式化时未开启 reflinkxfs_info /datagrep reflink内核版本太老内核不支持 XFS reflinkuname -r升级内核或改用 btrfs 测试6.2 扫描显示很多重复执行后空间没有下降这是去重实践中很常见的情况原因通常不是工具坏了而是候选重复并没有真正转化为空间收益。一种情况是检测到的重复块之前就已经被文件系统共享比如大量文件本来就是通过 reflink 复制出来的。另一种情况是块大小和对齐方式不理想两个文件虽然有相同内容但 logical offset 或物理块分布不满足合并条件。检查方法是分阶段观察oans /data/dedup-test --dry-run oans /data/dedup-test --apply df -h /data btrfs filesystem du --summarize /data/dedup-test如果 dry-run 显示大量重复但执行后df几乎没有变化可以调大块大小或换到碎片更少、写入更规整的目录再试。6.3 去重工具运行中系统响应变慢去重扫描会读取大量数据执行阶段还会产生大量元数据更新。如果生产环境出现明显卡顿优先降低并发和优先级。pkill -f oans /data # 停止当前去重进程 ionice -c 3 nice -n 19 oans /data/backup --threads 2 --apply同时检查系统负载top iostat -x 5如果iostat显示%util长期接近 100%说明磁盘已经吃满并发需要进一步降低。6.4 如何应对“误合并”担忧内核执行FIDEDUPERANGE时会逐字节比较因此误合并且在逻辑上几乎不可能。但任何工具都不应该替代备份。去重操作本身修改的是文件系统元数据一旦执行前没有备份遇到文件系统 bug 或硬件故障恢复成本会很高。建议在关键目录执行前先做快照或备份。btrfs 可以创建子卷快照XFS 可以依赖外部备份工具。备份完成后再执行去重。注意去重不等于压缩也不等于备份。空间紧张时去重可以延迟磁盘扩容但不能替代可靠性措施。7. 生产环境使用建议和扩展方向7.1 识别适合去重的目录去重不是所有重复问题的通用答案。实践中下面几类目录收益最明显备份目录多个时间点备份中大量未变化文件。虚拟机镜像存储同一模板创建的多台虚机。容器镜像和构建缓存不同层之间存在大量重复块。日志归档多份 gzip 或文本日志可能包含相同段落。不适合去重的目录包括数据库数据文件在线写入频繁CoW 复制会引入额外写放大。加密或压缩文件内容随机性高重复块少。大量小文件目录低于块大小的文件无法被有效合并。7.2 与快照、备份的协作btrfs 快照本身已经通过共享 extent 节省空间。如果目录已经存在大量快照再去重获得的额外收益可能有限反而会增加元数据压力。XFS 的 reflink 特性与备份系统结合时要注意备份工具是否支持 reflink 感知否则可能把共享文件当成普通文件完整读一遍造成备份时间暴涨。7.3 同类工具对比和选型Oans 并不是唯一的文件系统级去重工具。要根据场景选择合适的工具组合。工具适用文件系统工作方式适用场景duperemovebtrfs、XFS批量扫描 ioctl定期批量去重beesbtrfs后台持续去重长期自动维护 btrfsrmlint跨文件系统查找重复文件 可选调用 reflink清理重复文件并节省空间dduperbtrfs扫描 dedupebtrfs 专用Oansbtrfs、XFS强调 fast 的去重实现追求速度和批量处理选型时结合文件系统、定时任务需求和自动化程度考虑。后台持续去重工具如 bees适合 btrfs 长期在线维护但会持续占用 I/O一次性批量工具如 Oans、duperemove更适合安排在固定维护窗口执行。7.4 去重前的检查清单把下面这份清单打印出来每次执行去重前逐项确认[ ] 确认目标目录所在文件系统是 btrfs 或 XFS[ ] 确认内核版本满足文件系统 reflink 要求[ ] 检查挂载选项和 reflink 特性是否开启[ ] 已有完整备份或快照[ ] 确认磁盘有足够空间容纳索引和临时文件[ ] 确认目标目录没有正在高频写入的活跃文件[ ] 先执行 dry-run检查候选重复量和预计收益[ ] 低峰期执行并通过 ionice / nice 限制优先级[ ] 控制并发线程数避免打满磁盘 I/O[ ] 执行后验证文件哈希、空间变化和 extent 共享情况7.5 下一步可以扩展的方向去重只是磁盘空间治理的其中一个环节。实际生产环境中建议把去重纳入完整的存储生命周期管理先通过du、ncdu、filefrag找出空间占用大户再评估是归档、压缩、删除还是去重最合适。如果你对 btrfs 和 XFS 的 reflink 机制感兴趣可以继续学习cp --reflink、fiemap、xfs_io、btrfs filesystem du这组工具理解文件系统如何管理逻辑块与物理块的映射。掌握了这些再去读 Oans 源码时会发现核心逻辑其实就围绕四个点展开如何扫描文件、如何分块计算哈希、如何索引候选重复块、如何高效调用FIDEDUPERANGE。把这四部分串起来也就理解了一个快速去重工具的全部骨架。