如何知道我的 NVMe SSD 是否需要 TRIM

sot*_*rov 8 performance ssd trim disk nvme

在我的主笔记本电脑上运行 Ubuntu 22.04。我使用4TB 十铨 MP34 NVMe作为我的主驱动器。文件系统是ext4.

昨天(11 月 16 日),在下载一些大文件(大约 300 个文件,总共 600GB)时,突然我的笔记本电脑开始出现异常。一切都变得非常慢,我的系统崩溃了。我能够使用可启动 USB 和fsck. 然而,笔记本电脑的速度仍然很慢,并且 NVMe SSD 变得非常热,大约 75 摄氏度(通常低于 35 度)。磁盘只有大约 35% 已满。我在磁盘上运行基准测试,速度不一致并且非常慢。经过几分钟的工作后,磁盘进入只读模式。

最初,我认为存在一些硬件问题。我打开笔记本电脑并用异丙醇清洁触点。我换了另一个NVMe,笔记本电脑工作正常。我重新安装了最初的 NVMe,笔记本电脑又变得非常慢。在某个时候,我决定运行sudo fstrim -av,大约需要 5-6 分钟(经过修剪2.9TB),之后笔记本电脑开始像新的一样工作。我已经使用它超过 5 天了,没有任何问题。我做了一些压力测试和基准测试,一切正常。

我在 11 月 16 日编写的手册的输出sudo fstrim -av

/boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/nvme0n1p1
/: 2.9 TiB (3138692276224 bytes) trimmed on /dev/nvme0n1p2
Run Code Online (Sandbox Code Playgroud)

看起来fstrim.service工作正常:

cat /var/log/syslog | grep -a fstrim

Nov 13 01:43:37 dev fstrim[98095]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/nvme0n1p1
Nov 13 01:43:37 dev fstrim[98095]: /: 2.9 TiB (3140636598272 bytes) trimmed on /dev/nvme0n1p2
Nov 13 01:43:37 dev systemd[1]: fstrim.service: Deactivated successfully.
Run Code Online (Sandbox Code Playgroud)

最后的 TRIM 看起来更正常:

cat /var/log/syslog | grep -a fstrim
Nov 20 01:26:54 dev fstrim[109477]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/nvme0n1p1
Nov 20 01:26:54 dev fstrim[109477]: /: 31.5 GiB (33783455744 bytes) trimmed on /dev/nvme0n1p2
Nov 20 01:26:54 dev systemd[1]: fstrim.service: Deactivated successfully.
Run Code Online (Sandbox Code Playgroud)

NVMe 非常新且状况良好:

sudo smartctl -a /dev/nvme0

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.2.0-36-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       TEAM TM8FP4004T
Serial Number:                      xxxxxxxxxxxxxxxxxxxxx
Firmware Version:                   VB421D65
PCI Vendor/Subsystem ID:            0x10ec
IEEE OUI Identifier:                0x00e04c
Controller ID:                      1
NVMe Version:                       1.3
Number of Namespaces:               1
Namespace 1 Size/Capacity:          4,096,805,658,624 [4.09 TB]
Namespace 1 Formatted LBA Size:     512
Local Time is:                      Fri Nov 17 12:57:17 2023 EET
Firmware Updates (0x02):            1 Slot
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0014):     DS_Mngmt Sav/Sel_Feat
Log Page Attributes (0x02):         Cmd_Eff_Lg
Maximum Data Transfer Size:         32 Pages
Warning  Comp. Temp. Threshold:     100 Celsius
Critical Comp. Temp. Threshold:     110 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     8.00W       -        -    0  0  0  0   230000   50000
 1 +     4.00W       -        -    1  1  1  1     4000   50000
 2 +     3.00W       -        -    2  2  2  2     4000  250000
 3 -     0.50W       -        -    3  3  3  3     4000    8000
 4 -   0.0090W       -        -    4  4  4  4     8000   30000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        35 Celsius
Available Spare:                    100%
Available Spare Threshold:          32%
Percentage Used:                    0%
Data Units Read:                    4,447,105 [2.27 TB]
Data Units Written:                 8,885,998 [4.54 TB]
Host Read Commands:                 48,182,921
Host Write Commands:                112,476,615
Controller Busy Time:               0
Power Cycles:                       34
Power On Hours:                     2,423
Unsafe Shutdowns:                   11
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, 8 of 8 entries)
No Errors Logged
Run Code Online (Sandbox Code Playgroud)

输出journalctl | grep "fstrim.*/:"

Jul 03 00:21:43 dev fstrim[27756]: /: 3.6 TiB (4009258434560 bytes) trimmed on /dev/nvme0n1p2
Jul 10 00:54:49 dev fstrim[1244594]: /: 3.6 TiB (4001406066688 bytes) trimmed on /dev/nvme0n1p2
Jul 17 00:32:58 dev fstrim[4040993]: /: 54.6 GiB (58677125120 bytes) trimmed on /dev/nvme0n1p2
Jul 24 00:29:14 dev fstrim[1600660]: /: 138.8 GiB (149000179712 bytes) trimmed on /dev/nvme0n1p2
Jul 31 00:35:13 dev fstrim[620323]: /: 135.8 GiB (145785393152 bytes) trimmed on /dev/nvme0n1p2
Aug 07 00:13:04 dev fstrim[35853]: /: 2.9 TiB (3226885373952 bytes) trimmed on /dev/nvme0n1p2
Aug 14 00:29:27 dev fstrim[125210]: /: 2.9 TiB (3230223196160 bytes) trimmed on /dev/nvme0n1p2
Aug 21 01:32:45 dev fstrim[332311]: /: 56.8 GiB (61013270528 bytes) trimmed on /dev/nvme0n1p2
Aug 28 00:11:05 dev fstrim[586592]: /: 90.3 GiB (96974286848 bytes) trimmed on /dev/nvme0n1p2
Sep 04 01:28:47 dev fstrim[16608]: /: 3 TiB (3257704198144 bytes) trimmed on /dev/nvme0n1p2
Sep 11 00:22:26 dev fstrim[21637]: /: 2.9 TiB (3238865485824 bytes) trimmed on /dev/nvme0n1p2
Sep 18 01:14:48 dev fstrim[126317]: /: 2.9 TiB (3240947859456 bytes) trimmed on /dev/nvme0n1p2
Sep 25 00:22:54 dev fstrim[410142]: /: 36.2 GiB (38895230976 bytes) trimmed on /dev/nvme0n1p2
Oct 02 00:31:31 dev fstrim[90432]: /: 3 TiB (3249296408576 bytes) trimmed on /dev/nvme0n1p2
Oct 09 00:48:51 dev fstrim[319128]: /: 54.2 GiB (58184278016 bytes) trimmed on /dev/nvme0n1p2
Oct 16 01:11:15 dev fstrim[29502]: /: 2.8 TiB (3103039946752 bytes) trimmed on /dev/nvme0n1p2
Oct 23 00:31:40 dev fstrim[85578]: /: 2.9 TiB (3152333541376 bytes) trimmed on /dev/nvme0n1p2
Oct 30 01:16:53 dev fstrim[212523]: /: 2.9 TiB (3140076969984 bytes) trimmed on /dev/nvme0n1p2
Nov 06 01:11:08 dev fstrim[38462]: /: 2.9 TiB (3138336178176 bytes) trimmed on /dev/nvme0n1p2
Nov 13 01:43:37 dev fstrim[98095]: /: 2.9 TiB (3140636598272 bytes) trimmed on /dev/nvme0n1p2
Nov 20 01:26:54 dev fstrim[109477]: /: 31.5 GiB (33783455744 bytes) trimmed on /dev/nvme0n1p2
Run Code Online (Sandbox Code Playgroud)

虽然是一个老问题,但这与上面的数字有关: 运行 fstrim 后修剪的大量数据。我不经常重新启动笔记本电脑,几周的正常运行时间对我来说是正常的。

我使用SSD已经很多年了,这是我第一次遇到这样的问题。这也是我第一次必须fstrim手动执行。所以,我有点疑惑。是什么导致了这种行为?正常吗?有没有办法知道我的 NVMe SSD 是否需要 TRIM?

Art*_*ild 5

“如何知道我的 NVMe SSD 是否需要 TRIM”

由于我无法解释您所经历的现象,因此我也无法确定原因是什么,以及您应该监控哪些确切标准。

sudo fstrim -av然而,这将更多地是您可以监视的指针的集合,并根据这些指针自行决定是否要先发制人地采取行动(使用 进行额外的手动修剪)。

所以这是我的建议:

  1. 监视 的输出fstrim.service。如果削减过多(例如超过 1 TB),则可能需要采取行动。
  2. 监控自上次修剪以来您下载了多少 GB 数据。如果这超出了总磁盘大小的阈值 (25-50%),请考虑采取措施。
  3. 监控SSD写入速度。如果它低于规定值的一半(或低于 250 MB/s - 但与您的情况无关),请采取行动。

这个列表中可能还有更多可行的指标。

测试fstrim.service性能

我在自己的机器上进行了测试,现在我可以确认对我而言,它的执行效果与 @sotirov 和 @FedKad 在评论和本问答fstrim.service中所述完全相同。

这是我的输出journalctl -t fstrim(行已缩短):

Oct 23 00:04:55 xb fstrim[662497]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Oct 23 00:04:55 xb fstrim[662497]: /: 442 GiB (474638336000 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c753d>
-- Boot 34c888b0968f458084fa1cf674269326 --
Oct 30 00:04:53 xb fstrim[1303597]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Oct 30 00:04:53 xb fstrim[1303597]: /: 442.1 GiB (474652139520 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c7>
-- Boot 04117f235c354c1fb3c4f082bae4f563 --
Nov 06 00:16:25 xb fstrim[612946]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Nov 06 00:16:25 xb fstrim[612946]: /: 442 GiB (474547269632 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c753d>
Nov 13 00:19:03 xb fstrim[3960792]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Nov 13 00:19:03 xb fstrim[3960792]: /: 253.8 GiB (272512958464 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c7>
Nov 20 00:02:50 xb fstrim[2878811]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Nov 20 00:02:50 xb fstrim[2878811]: /: 258.4 GiB (277492928512 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c7>
Run Code Online (Sandbox Code Playgroud)

这里很明显的是:

  1. fstrim.service首次启动后修剪整个磁盘。
  2. fstrim.service然后随后修剪相当大的数量(253.7 GiB 和 258.4 GiB)

然后复制@sotirov的帖子,我尝试fstrim手动运行,这导致了另一个大量的结果:

/: 274.1 GiB (294319964160 bytes) trimmed
Run Code Online (Sandbox Code Playgroud)

然后,当fstrim第二次手动运行时,数字就大不相同了:

/: 84.3 MiB (88375296 bytes) trimmed
Run Code Online (Sandbox Code Playgroud)

这证实了 的行为fstrim。也许这种行为是有问题的,或者也许我只是不明白其中的巨大差异。

我可以告诉的是,手动运行后,修剪的块数量会大大减少fstrim。另外,我没有注意到任何性能差异,所以就我而言,这似乎并不重要。

技术细节:

有关如何测量修剪数据的示例fstrim.service(按照项目符号 1):

Oct 23 00:04:55 xb fstrim[662497]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Oct 23 00:04:55 xb fstrim[662497]: /: 442 GiB (474638336000 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c753d>
-- Boot 34c888b0968f458084fa1cf674269326 --
Oct 30 00:04:53 xb fstrim[1303597]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Oct 30 00:04:53 xb fstrim[1303597]: /: 442.1 GiB (474652139520 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c7>
-- Boot 04117f235c354c1fb3c4f082bae4f563 --
Nov 06 00:16:25 xb fstrim[612946]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Nov 06 00:16:25 xb fstrim[612946]: /: 442 GiB (474547269632 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c753d>
Nov 13 00:19:03 xb fstrim[3960792]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Nov 13 00:19:03 xb fstrim[3960792]: /: 253.8 GiB (272512958464 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c7>
Nov 20 00:02:50 xb fstrim[2878811]: /boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/disk/by-uuid/A49B-17AD
Nov 20 00:02:50 xb fstrim[2878811]: /: 258.4 GiB (277492928512 bytes) trimmed on /dev/disk/by-uuid/f9c4d8ff-bfd6-404b-944e-4c7>
Run Code Online (Sandbox Code Playgroud)

有关如何测量 SSD 写入速度的示例(按照第 3 点 - 运行此脚本root):

/: 274.1 GiB (294319964160 bytes) trimmed
Run Code Online (Sandbox Code Playgroud)

  • 您可以添加一个指针来指示如何执行第三点吗? (2认同)
  • 第 1 点可能与 https://askubuntu.com/q/729279/1157209 相关:操作系统重新启动后,第一次运行 fstrim 会将操作系统已知的**所有**空块发送到 SSD 进行恢复。 (2认同)
  • 我在脚本中添加了“conv=f​​datasync”,这应该确保刷新缓冲区。 (2认同)