ZFS scrub能否更新已有数据的压缩配置与副本数？

好问题！这是ZFS用户常碰到的误区，我来给你拆解清楚：

核心结论：ZFS Scrub完全不会应用新属性到已有数据 #

Scrub的本职工作是校验数据完整性、修复损坏的副本，它不会主动重写已有数据来适配你后来修改的copies或compression设置。具体来说：

• 对于copies=2改copies=1：旧数据的2份副本会原封不动保留，scrub不会自动删除多余的那份；新写入的数据才会只生成1份副本。
• 对于compression=lz4改compression=gzip-9：旧数据还是保持lz4的压缩状态，scrub不会触发重压缩，只有新写入的数据会用gzip-9压缩。

把新属性应用到已有数据的两种可行方法 #

方法1：手动复制重写（适合单个/少量文件） #

这是最直接的方式，通过让ZFS重新写入数据来触发新属性生效：

• 假设你的1TB文件在tank/storage/bigfile，先复制到同池的临时文件：

  cp -a tank/storage/bigfile tank/storage/bigfile.tmp
  

• 删除原文件：rm tank/storage/bigfile
• 把临时文件改回原名：mv tank/storage/bigfile.tmp tank/storage/bigfile

注意：操作前要确保存储池有足够的空闲空间（至少等于原文件大小），因为复制过程会占用额外空间。

方法2：ZFS快照发送接收（适合整个数据集批量处理） #

如果是整个数据集（比如tank/storage）需要统一更新属性，用zfs send/receive效率更高：

1. 给目标数据集创建快照：

   zfs snapshot tank/storage@update_attr
   

2. 将快照发送到同池的临时数据集，接收时会自动应用当前的数据集属性：

   zfs send tank/storage@update_attr | zfs receive tank/storage_new
   

3. 验证新数据集的数据和属性都没问题后，交换两者的名称：

   zfs rename tank/storage tank/storage_old
   zfs rename tank/storage_new tank/storage
   

4. 确认无误后删除旧数据集：

   zfs destroy tank/storage_old
   

这个方法的优势是能批量处理所有数据，而且zfs send/receive支持增量操作，后续如果有类似需求会更高效。

关于copies属性的额外说明 #

如果是从copies=2降到copies=1，其实不用急着重写数据——当ZFS需要回收空间时（比如池空间不足，或者执行zfs trim），它会自动清理掉超出当前copies设置的多余副本。不过这个过程是被动触发的，不会立刻完成；如果想立刻生效，还是要用上面的重写方法。

内容的提问来源于stack exchange，提问作者unfa