我在 Samsung EVO SSD 上使用 btrfs 作为加密分区 (luks)。磁盘发生故障的速度比预期的要快。我如何评估 ext4 在这些磁盘上对我的使用是否更可靠，或者什么使用更有可能导致其磨损程度？
背景
在我的台式电脑上作为根磁盘和主磁盘使用大约两年后，我的三星 SSD 870 EVO 500GB 开始出现故障，出现数百个坏块和数千个无法纠正的错误：
$ sudo smartctl -a /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.2.15-100.fc36.x86_64] (local build)
=== START OF INFORMATION SECTION ===
Device Model: Samsung SSD 870 EVO 500GB
Firmware Version: SVT01B6Q
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Self-test execution status: ( 121) The previous self-test completed having
the read element of the test failed.
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 19378
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 69
177 Wear_Leveling_Count 0x0013 098 098 000 Pre-fail Always - 44
183 Runtime_Bad_Block 0x0013 065 065 010 Pre-fail Always - 200
187 Uncorrectable_Error_Cnt 0x0032 099 099 000 Old_age Always - 2696
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 59
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 83504703737
磁盘相当繁忙，但远远低于保修限制5 年或 300 TB TBW。
它的前身是三星 850 EVO 250 GB，使用 5 年后处于类似状态。也许新磁盘只是比以前的磁盘更差，但我开始想知道是否有一个共同因素。
他们分享的一件事是我在上面安装了 Fedora，最近 Fedora 开始默认使用 btrfs（至少对于 luks 文件系统），而不是 ext4（我相信以前的磁盘大部分时间都是 ext4）。例如，Fedora 38 默认创建此布局：
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465,8G 0 disk
├─sda1 8:1 0 600M 0 part /boot/efi
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 464,2G 0 part
└─luks-<redacted> 253:0 0 464,2G 0 crypt /home
/
$ mount | grep luks
/dev/mapper/luks-<redacted> on / type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=257,subvol=/root)
/dev/mapper/luks-<redacted> on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=256,subvol=/home)
$ mount | grep sda
/dev/sda2 on /boot type ext4 (rw,relatime,seclabel)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
几年前，情况类似，但没有压缩以及其他一些 btrfs 参数。
在讨论了 COW（写时复制）之后，btrfs 文档包含了许多内容SSD 警告:
写入“太多”不同的数据（例如加密的）可能会使内部重复数据删除无效，并导致大量重写和增加存储单元的磨损。由于缺乏有关 SSD 工作原理的信息或设备提供的可靠统计数据，无法可靠地确定 SSD 的预期寿命。只有消耗 SSD 实际生命周期写入量 50% 到 100% 的用户才需要关心 btrfs DUP 元数据的写入放大。
所以听起来我已经达到了磁盘实际寿命的 50% 以上，尽管我的写入量比保修承诺的要少一个数量级，而且我应该担心 btrfs 的 SSD 磨损。
使用模式
我现在注意到你应该运行一个BTRFS磨砂膏每月以及停电等事件发生后：
用户应该手动或通过定期系统服务运行它。建议的期限是一个月，但也可以更短。
我从来没有这样做过。无论如何，最常访问的文件在某些时候都会被检查和修复。我的损坏文件往往位于较旧且访问较少的一侧。
（如果这很重要，那就奇怪了。我的另一个带有 luks+lvm+ext4 的 SSD 有超过 10k 的电源周期，根据 SMART，没有任何问题。）
可能的想法
人们通常建议不要在 btrfs 上运行数据库或其他类似的写入密集型负载。
我不知道上述建议是否真实/当前，但我的电脑上没有运行任何数据库。另一方面，前一个磁盘最具破坏性的故障发生在 Thunderbird 用于消息存储的区域（其中有几 GB 的 mbox 文件；此后我已切换到 Maildir）。我想知道我的电脑上是否有一些类似数据库的负载，我可以不用，或者移动到另一个文件系统。 （我已经禁用了 baloo。）
是否存在一些基准测试工具或实用程序来判断哪些应用程序对文件系统产生了最多的写入（或最有可能的磨损）？
或者，是否有基准测试工具或实用程序可以对某个文件系统-磁盘组合进行压力测试，并查看各种情况下对磁盘自我报告磨损的影响？