一个受害者的留言：

不久前（约一年前）我设置了一个这样的系统：

在第二个 NVMe 硬盘上使用 Luks2+btrfs。加密方式为 AES-XTS，采用 256 位密钥，同时搭配使用 zstd 压缩级别 7 的 btrfs 文件系统。该分区挂载到/data 目录下，用于存储那些即使丢失我也毫不畏惧的数据（如 Steam 游戏、音乐、电视剧等）。通过 fstab 和 crypttab 结合密钥文件实现自动挂载，无需快照或复杂的子卷设置，我只需享受压缩带来的好处。整个过程中从未发生过非正常关机的情况。

它的压缩效果很好，当我发现 300GB 的存储空间实际仅使用了 215GB 时，简直太棒了。直到有一天，压缩效果变得如此出色，以至于文件被压缩到了零字节大小。

这个文件系统“在遇到一些不可恢复的错误之前不需要运行 fsck”……

我绝对不会再信任那个文件系统了。幸好丢失的数据对我而言并不重要。

I had one not long ago(1 year)

Luks2+btrfs on the second nvme. Aes-xts plain, 256bit keysizs + btrfs with zstd lvl 7 compression. Mounted in /data and used to hold crap that I would not be afraid if I lose (Steam games, music, series, etc). Automount with fstab+crypttab using a keyfile, no snapshots, no complex sub volume setups, I just wanted to benefit from the compression. No unclean shutdowns whatsoever.

It had good compression and I've hit a level where 300GB was actually using only 215GB, fantastic. Until the day where compression worked so awesomely that compressed to zero.

This filesystem "does not need fsck" until you hit some unrecoverable errors...

I would not trust that filesystem never again. Luckily it was data that I would not care much if I lose it.
--
FROM 171.221.52.*