BLOG: Determine and modernize Filesystem Deduplication

refs native dedup去重服务似乎无法自动处理numa拓扑，只会使用cpu0。不过，通过任务管理器手动分配全部核心似乎可以正确的在cpu0和cpu1之间缩放全部线程，暂时没有观察到块腐败。

其次，去重中内存消耗出奇的大，不但去重服务需要消耗大量内存，似乎内核refs元数据缓存也会大量增长，不清楚这是否是预期的行为。或许引入一个内存限制选项是个不错的方案就像经典去重那样。

同时，refs native dedup的去重速度似乎比经典去重慢得多。我使用相同的数据集（过时并存档的windows vm）在相同的硬件相同版本的宿主系统上多次运行，refs dedup服务在工作一段时间后就会进入“冻结”状态，我推测这与nvme磁盘上极大队列长度有关。去重服务似乎非常依赖写入和读取一个隐藏的db文件，并且很难以“非常快”的速度写入。

总之我非常喜爱refs native dedup，也非常认可依赖块克隆所带来的优势，并且还能享受完整性流带来的可靠与安心。然而，还是希望能够有更多的文档和更好的易用性。

这样更多的场景和负载就能从经典去重迁移到更现代的堆栈上。