Início / ubuntu / Perguntas / 1492995
Accepted
sotirov
Asked: 2023-11-17 20:21:27 +0800 CST

Como saber se meu SSD NVMe precisa de TRIM

  • 772

Executando o Ubuntu 22.04 no meu laptop principal. Estou usando 4 TB TEAMGROUP MP34 NVMe como minha unidade principal. O sistema de arquivos é ext4.

Ontem (16 de novembro), enquanto baixava alguns arquivos grandes (cerca de 300 arquivos, 600 GB no total), de repente meu laptop começou a funcionar de maneira estranha. Tudo ficou muito lento e meu sistema travou. Consegui repará-lo com um USB inicializável e um arquivo fsck. No entanto, o laptop ainda estava muito lento e o SSD NVMe estava esquentando muito, cerca de 75 graus Celsius (geralmente é menos de 35 graus). O disco estava apenas 35% cheio. Executei o benchmark no disco e as velocidades eram inconsistentes e muito lentas. Após vários minutos de trabalho, o disco entrou no modo somente leitura.

Inicialmente, pensei que havia algum problema de hardware. Abri o laptop e limpei os contatos com álcool isopropílico. Troquei o NVMe por outro e o laptop funcionou normalmente. Instalei meu NVMe inicial e o laptop ficou muito lento novamente. Em algum momento eu decidi rodar sudo fstrim -av, demorou cerca de 5-6 minutos (cortado cerca de 2.9TB) e depois disso o laptop começou a funcionar como novo. Estou usando sem problemas há mais de 5 dias. Fiz alguns testes de estresse e benchmarks, tudo funciona normalmente.

O resultado do manual sudo fstrim -avque fiz em 16 de novembro:

/boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/nvme0n1p1
/: 2.9 TiB (3138692276224 bytes) trimmed on /dev/nvme0n1p2

Parece que fstrim.serviceestava funcionando bem:

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.

O último TRIM parece mais normal:

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.

O NVMe é bem novo e está em boas condições:

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

Saída de 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

Embora seja uma questão antiga, está relacionada aos números acima: Grande quantidade de dados cortados após a execução de fstrim . Não reinicio meu laptop com muita frequência e é normal que eu tenha algumas semanas de atividade.

Uso SSDs há anos e é a primeira vez que estou enfrentando um problema como esse. Também foi a primeira vez que tive que executar fstrimmanualmente. Então, estou um pouco confuso. O que poderia ter causado esse comportamento? Isso é normal? Existe uma maneira de saber se meu SSD NVMe precisa de TRIM?

ssd

1 respostas

  1. Best Answer

    "Como saber se meu SSD NVMe precisa de TRIM"

    Como não posso explicar o fenômeno que você vivencia, também não posso dizer com certeza qual é o motivo e quais critérios exatos você deve monitorar.

    No entanto, esta será mais uma coleção de indicadores que você pode monitorar e decidir por si mesmo se deseja agir preventivamente (fazer um corte manual extra com sudo fstrim -av) com base neles.

    Então aqui estão minhas sugestões:

    1. Monitore a saída do fstrim.service. Se cortar uma quantidade excessiva (como mais de 1 TB), talvez tome medidas.
    2. Monitore quantos GB de dados você baixou desde o último corte. Se isso exceder o limite do tamanho total do disco (25-50%), considere tomar medidas.
    3. Monitore a velocidade de gravação do SSD. Se for menos da metade do valor declarado (ou menos de 250 MB/s - não relevante no seu caso) , tome medidas.

    Pode haver indicadores mais viáveis ​​nesta lista.

    Testando fstrim.servicedesempenho

    Testei em minha própria máquina e agora posso confirmar que fstrim.servicepara mim funciona exatamente como declarado por @sotirov e @FedKad nos comentários e nestas perguntas e respostas .

    Esta é a minha saída de journalctl -t fstrim(as linhas são encurtadas):

    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>

    É evidente aqui que:

    1. fstrim.servicecorta todo o disco após a primeira inicialização.
    2. fstrim.serviceem seguida, corta uma quantidade bastante grande (253,7 GiB e 258,4 GiB) posteriormente

    Depois replicando o post do @sotirov, tentei rodar fstrimmanualmente, o que resultou em outra grande quantidade:

    /: 274.1 GiB (294319964160 bytes) trimmed

    E então, ao executar fstrimmanualmente pela segunda vez, o número é muito diferente:

    /: 84.3 MiB (88375296 bytes) trimmed

    Isso confirma o comportamento de fstrim. Talvez esse comportamento seja problemático ou talvez eu simplesmente não entenda a enorme diferença.

    O que posso dizer é que o número de blocos cortados é reduzido drasticamente após a execução fstrimmanual. Além disso, não notei nenhuma diferença de desempenho, então, no meu caso, parecia que isso realmente não importava.

    Detalhes técnicos:

    Exemplo de como medir os dados cortados por fstrim.service(conforme marcador 1):

    #!/bin/bash

# Set threshold for SSD trim
threshold=500

# Get the latest trim value
ssdvalue=$(journalctl -t fstrim | tail -n 1 | awk '{ print $7 }')

# If value is smaller than threshold, then OK - else do something
### The logic should probably be reworked here, when dealing with Terrabytes of data - probably by using numfmt command or something similar
if [[ "${ssdvalue%.*}" -lt "$threshold" ]]
then
  echo "Everything OK"
else
  echo "Do something (run fstrim)"
fi

    Exemplo de como medir a velocidade de gravação do SSD (conforme item 3 - execute este script como root):

    #!/bin/bash

# Set path to SSD disk (to write benchmark file)
ssdpath=/path/to/ssd/

# Set threshold for write speed
threshold=1000

# Remove file if it exists
[[ -f "$ssdpath/ssdwrite" ]] && rm "$ssdpath/ssdwrite"

# Run dd command to test write speed
dd if=/dev/zero of="$ssdpath/ssdwrite" conv=fdatasync bs=1G count=5 status=progress 2> /dev/shm/ssdspeed

# Isolate the MB/s value
ssdvalue=$(tail -n 1 /dev/shm/ssdspeed | awk '{ print $10 }')

# If value is larger than threshold, then OK - else do something
if [[ "$ssdvalue" -gt "$threshold" ]]
then
  echo "Everything OK"
else
  echo "Do something (run fstrim)"
fi
    • 5

relate perguntas