ZFS的ARC缓存非越大越好，arc_max过高会引发内存压力与pageout振荡；lz4压缩在高同步写场景下可能成为瓶颈；加密启用后需避免keylocation=prompt以防止密钥派生延迟；arc_reclaim_strategy参数在ZFS 2.1+已移除，实际应调优arc_min和arc_meta_limit。
arc_max 设置太高反而拖慢随机读？
ZFS 的 ARC 缓存不是“越大越好”，尤其在内存紧张或混合负载场景下。arc_max 设得过高，会导致内核内存压力升高，触发频繁的 kswapd 回收，甚至引发 pageout 振荡——你看到的现象可能是：小文件随机读延迟飙升、zpool iostat -v 显示大量 ARC miss 却伴随高 memory pressure。
- 生产中建议把
arc_max控制在物理内存的 50%～70%，且必须预留至少 4GB 给内核和用户进程（特别是 PostgreSQL 或 Redis 这类吃内存的服务） - 不要直接写死
/sys/module/zfs/parameters/zfs_arc_max，优先用echo 12884901888 > /sys/module/zfs/parameters/zfs_arc_max（即 12G）临时验证，再写入/etc/modprobe.d/zfs.conf：options zfs zfs_arc_max=12884901888
- 注意：该值必须是 8 字节对齐的整数，否则加载模块时会静默失败，
dmesg | grep arc会报invalid parameter
lz4 压缩开启后写入变慢，是不是该关掉？
不是压缩本身慢，而是压缩 + 同步写 + 高 IOPS 场景下的资源争抢。lz4 在 CPU 充足时几乎无开销，但若遇到 sync=always 或应用频繁调用 fsync()（如 MySQL binlog、Kafka 日志），压缩会卡在 ZIO pipeline 的 zio_compress 阶段，表现为 zpool iostat -v 中 WRITE 延迟跳升、zpool status 出现 scrub/resilver in progress 却无实际进度。
- 默认启用
compression=lz4是安全的，但以下情况建议关闭：- 数据集主要存已压缩格式（如 JPEG、MP4、gzip 日志）
- CPU 负载长期 > 70%，且
mpstat -P ALL 1显示%iowait低而%sys高 - 使用 NVMe 且追求极致延迟（如高频交易日志）
- 关闭命令：
zfs set compression=off pool/dataset，注意它只影响新写入，旧数据不会自动解压
启用 encryption=on 后克隆变慢、快照列表卡顿
ZFS 加密（特别是 encryption=on + keylocation=prompt）会让每个数据集操作都触发密钥派生（PBKDF2）和密钥缓存查找。这不是加密算法慢，而是密钥管理路径未被充分缓存——典型表现是：zfs list -t snapshot 延迟从毫秒级升到秒级，zfs clone 时卡在 keystore_lookup_key。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 必须配合
keylocation=file:///path/to/key或keylocation=pkcs11:使用，避免交互式输入；生产环境禁用prompt - 密钥文件权限必须为
0400且属主为 root，否则 ZFS 会拒绝读取并 fallback 到 prompt - 如果用
keyformat=passphrase，务必确认pbkdf2iters没被手动调高（默认 350000 安全够用），调到百万级会导致单次 key load 耗时超 200ms
arc_reclaim_strategy=aggressive 真的能缓解内存抖动？
不能，而且大概率让问题更糟。arc_reclaim_strategy 是个误导性参数：ZFS 从 2.1 开始已移除该选项，任何尝试写入 /sys/module/zfs/parameters/arc_reclaim_strategy 的操作都会返回 Invalid argument，但系统不会报错提示，只会默默忽略——你改了等于没改。
- 真正影响 ARC 回收节奏的是
zfs_arc_min和zfs_arc_meta_limit，前者控制 ARC 下限（建议设为1G防止冷数据全刷出），后者限制元数据缓存占比（默认 25%，高 metadata 负载如小文件多的数据集可提到 35%） - 若观察到 ARC 频繁震荡（
arcstat -o中size列上下跳变 >20%），优先检查是否启用了primarycache=all但数据集又设置了recordsize=64k——这种组合会让 ARC 缓存大量细碎 buffer，回收效率极低
ZFS 的缓存与加密不是开关式配置，每个参数背后都连着内存路径、密钥生命周期、I/O 栈深度。调参前先跑 arcstat -v 1 和 zpool iostat -v 1 看 5 分钟真实毛刺点，比查文档更快定位瓶颈。
