Fstrim
Introduction
Un disque SSD (Solid State Disk), comme les disques M.2 (SATA ou NVMe), ne sont pas forcément synchronisés entre le contrôleur et votre kernel.
La commande fstrim permet donc d’informer le contrôleur que certains blocs logiques (NAND) sont libres.
Contrôle de disque
$ lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 0B 0B 0
└─sda1 0 0B 0B 0
sdb 0 512B 2G 0
├─sdb1 0 512B 2G 0
└─sdb2 0 512B 2G 0
├─vgsteel-sys 0 512B 2G 0
├─vgsteel-swap 0 512B 2G 0
├─vgsteel-home 0 512B 2G 0
└─vgsteel-local 0 512B 2G 0
sdc 0 0B 0B 0
└─sdc1 0 0B 0B 0
sr0 0 0B 0B 0
Ici, mon disque sdb présente :
- DISC-GRAN (Discard Granularity)
👉 Taille minimale que le périphérique accepte pour une opération TRIM. Il accepte des TRIM à partir de 512 octets minimum. (c’est très précis)
- DISC-MAX (Discard Maximum)
👉 Taille maximale qu’on peut envoyer en une seule commande TRIM. Le kernel peut envoyer jusqu’à 2 Go de discard en une seule commande. (c’est bien)
Les autres disques sont des disques-durs classiques (à disques magnétiques), et ne sont donc pas concernés.
sous Debian
Debian a un contrôle programmé, pré-installé :
$ systemctl status fstrim.timer
○ fstrim.timer - Discard unused filesystem blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabl>
Active: inactive (dead)
Job: 163
Trigger: n/a
Triggers: ● fstrim.service
Docs: man:fstrim
$ systemctl cat fstrim.timer
# /usr/lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused filesystem blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release
[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=100min
[Install]
WantedBy=timers.target
On peut voir ici, qu’il est exécuté une fois par semaine.
[Timer]
OnCalendar=weekly
Conclusion
Debian se charge de ce nettoyage, mais la raison pour laquelle j’en suis venu à investiguer en ce sens, provient du fait que mon propre disque commence à montrer des signes de faiblesse :
$ sudo smartctl -a /dev/sdb | grep -E "197|198|194"
194 Temperature_Celsius 0x0022 042 051 000 Old_age Always - 42 (0 18 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 2
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
2 Pending Sectors → Pas bon !
$ sudo fstrim -v /
/ : 21,9 GiB (23496540160 octets) réduits
$ sudo smartctl -a /dev/sdb | grep -E "197|198|194"
194 Temperature_Celsius 0x0022 042 051 000 Old_age Always - 42 (0 18 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
→ Récupérés ! Soulagé !
Oui un disque qui montre des signes de faiblesse de la sorte, j’ai déjà connu ça : quand le crash se profile, sans sauvegardes, c’est le drame !