Activation, vérification du TRIM et comparaison des performances

  1. La commande TRIM est-elle prise en charge ?
  2. Mes partitions sont-elles alignées ?
  3. Mon kernel est compatible ?
  4. Méthode automatique depuis /etc/fstab avec le flag discard
  5. Méthode manuelle depuis une tâche cron avec la commande fstrim
  6. Utilisation réduite du SWAP
  7. Cache de Firefox en RAM
  8. Vérification du bon fonctionnement
  9. Comparaison des performances entre la méthode manuelle et automatique
  10. Références et remerciements

1. La commande TRIM est-elle prise en charge ?

[root@local ~]$ hdparm -I /dev/sdX | grep TRIM
    Data Set Management TRIM supported (limit 8 blocks)
    Deterministic read data after TRIM

Si la commande vous retourne TRIM supported (limit 1 block) ou TRIM supported (limit 8 block), c'est prit en charge.

Dans le cas où cela n'est pas prit en charge, vous pouvez vérifier plusieurs choses :

  • Activer AHCI dans le BIOS / UEFI
  • Mettre à jour le firmware du SSD

2. Mes partitions sont-elles alignées ?

Avec blockdev :

[root@local ~]$ blockdev --getalignoff /dev/<partition>

La commande doit retourner 0.

Avec fdisk :

[root@local ~]$ fdisk -lu /dev/sdX
    Disk /dev/sdX: 29,8 GiB, 32017047552 bytes, 62533296 sectors
    Unités : secteur de 1 × 512 = 512 octets
    Taille de secteur (logique / physique) : 512 octets / 512 octets
    taille d'E/S (minimale / optimale) : 512 octets / 512 octets
    Type d'étiquette de disque : dos
    Identifiant de disque : 0x0002e15d

    Périphérique Amorçage     Début       Fin    Blocs  Id Système
    /dev/sda1                  2048   1953791   975872  82 Linux swap / Solaris
    /dev/sda2    *          1953792  62531583 30288896  83 Linux

Le début de chaque partition doit être un multiple de 2048, dans mon cas 2048/2048=1 et 1953792/2048=954, c'est donc correct.

Avec parted :

[root@local ~]$ parted /dev/sdX
    GNU Parted 3.1
    Utilisation de /dev/sdX
    Bievenue sur GNU Parted ! Tapez 'help' pour voir la liste des commandes.
(parted) print
    Modèle: ATA SanDisk SDSSDRC0 (scsi)
    Disque /dev/sdX : 32,0GB
    Taille des secteurs (logiques/physiques): 512B/512B
    Table de partitions : msdos
    Disk Flags:
    Numéro  Début   Fin     Taille  Type     Système de fichiers  Fanions
     1      1049kB  1000MB  999MB   primary  linux-swap(v1)
     2      1000MB  32,0GB  31,0GB  primary  ext4                 démarrage
(parted) align-check opt 1
    1 aligné(es)
(parted) align-check opt 2
    2 aligné(es)
(parted) quit

Dans mon cas j'ai 2 partitions à vérifier avec align-check.

3. Mon kernel est compatible ?

[root@local ~]$ uname -r
    3.13.6-1-ARCH

La version du kernel doit être supérieur ou égal à 2.6.33.

4. Méthode automatique depuis /etc/fstab avec le flag discard

Il est généralement conseillé d'invoquer la commande fstrim depuis une tâche cron mais si perdre quelques millisecondes à la suppression n'est pas un problème pour vous, cette méthode est de loin la plus pratique.

Soyez certains de remplir toutes les conditions afin de continuer au risque de perdre des données.

  • Pour activer le support du TRIM nous allons ajouter le flag discard
  • Pour désactiver l'écriture de la dernière date d'accès à un fichier nous allons utiliser le flag noatime qui par défaut est relatime
  • /tmp est déjà un tmpfs par défaut, inutile donc de faire des modifications, vous pouvez vérifier avec mount

/etc/fstab :

# /dev/sda2
UUID=73a41527-91bf-2eff-8124-77b3a9b786ae / ext4 defaults,noatime,discard 0 1

5. Méthode manuelle depuis une tâche cron avec la commande fstrim

Soyez certains de remplir toutes les conditions afin de continuer au risque de perdre des données.

  • Pour désactiver l'écriture de la dernière date d'accès à un fichier nous allons utiliser le flag noatime qui par défaut est relatime
  • /tmp est déjà un tmpfs par défaut, inutile donc de faire des modifications, vous pouvez vérifier avec mount
  • Création d'une tâche daily ou weeky cron grâce à anacron

/etc/fstab :

# /dev/sda2
UUID=73a41527-91bf-2eff-8124-77b3a9b786ae / ext4 defaults,noatime 0 1

Si ce n'est pas déjà fait, cronie.service doit être activé :

[root@local ~]$ systemctl enable cronie.service
[root@local ~]$ systemctl start cronie.service

/etc/cron.daily/fstrim :

#!/bin/sh
fstrim /

Vous pouvez enregistrer le fichier dans /etc/cron.daily/ ou /etc/cron.weekly/.

Si vous avez plusieurs partitions vous pouvez utiliser une boucle for :

#! /bin/sh
for mount in / /boot /home; do
    fstrim $mount
done

Afin d'être certain du bon déroulement de la tâche cron et si cron n'est pas capable de vous délivrer un email (-m off), on peut rediriger provisoirement la sortie vers un fichier log :

/etc/cron.daily/fstrim :

#!/bin/sh
fstrim -v / >> /root/fstrim.log

Après une journée et la consultation du fichier /root/fstrim.log, si tout semble correct, on peut supprimer /root/fstrim.log et modifier la tâche cron pour ne plus créer ce fichier de log.

6. Utilisation réduite du SWAP

Le SWAP est généralement très peu utilisé, voir pas du tout, mais il est tout de même conseillé d'avoir cet espace d'échange.

Nous allons donc réduire l'utilisation du SWAP au profit de la RAM en réduisant le swapiness, qui de base est à 60 et le régler sur la valeur 5.

Cela veut dire que le SWAP commencera a être utilisé qu'à partir du moment ou il ne restera que 5% de RAM libre.

De cette façon il y a très peu de chance que le SWAP soit utilisé, mise à part dans le cas d'une veille prolongée.

Nous allons aussi passer vfs_cache_pressure de 100 à 50.

Modification/Création du fichier /etc/sysctl.d/99-sysctl.conf (Arch Linux) ou /etc/sysctl.conf :

vm.swappiness=1
vm.vfs_cache_pressure=50

7. Cache de Firefox en RAM

De base Firefox utilise déjà la RAM mais cela ne coûte rien de faire une vérification :

  • Barre d'adresse : about:config
  • Rechercher : browser.cache.disk.enable

La valeur doit être sur true.

8. Vérification du bon fonctionnement

On redémarre le système puis on se place dans un terminal en root depuis lequel on va créer un fichier d'une taille d'environ 4 Mo :

[root@local ~]$ dd if=/dev/urandom of=testfile count=1 bs=4M oflag=direct
    1+0 enregistrements lus
    1+0 enregistrements écrits
    4194304 octets (4,2 MB) copiés, 0,331989 s, 12,6 MB/s
[root@local ~]$ sync

On cherche ou le fichier est stocké physiquement sur le disque :

[root@local ~]$ hdparm --fibmap testfile
    testfile:
     filesystem blocksize 4096, begins at LBA 1953792; assuming 512 byte sectors.
     byte_offset  begin_LBA    end_LBA    sectors
               0    6877184    6881279       4096
         2097152    6746112    6750207       4096

Dans mon cas, ça commence au secteur 6746112.

Lecture à partir du secteur 6746112 :

[root@local ~]$ hdparm --read-sector 6746112 /dev/sda
    /dev/sda:
    reading sector 6746112: succeeded
    aa6c 19c2 933e b3f1 1adb 300b 4711 3f47
    9c82 5976 4cdc 8cc4 efff 291c dac6 3aff
    15e3 9a4a 549d 084d b244 de23 8151 85f2
    7ea7 7d12 87c9 cb09 e0a8 f515 5f86 e0f7
    […]

On efface le fichier :

[root@local ~]$ rm testfile
[root@local ~]$ sync

Seulement dans le cas où vous utilisez fstrim avec la méthode manuelle (cron) :

[root@local ~]$ fstrim -v /

Dans mon cas le fichier /root/testfile est stocké sur /.

On relit les secteurs :

[root@local ~]$ hdparm --read-sector 6746112 /dev/sda
    /dev/sda:
    reading sector 6746112: succeeded
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    […]

Vous obtenez 32 lignes contenant que des 0 ? ça fonctionne correctement.

9. Comparaison des performances entre la méthode manuelle et automatique

Le flag discard TRIM immédiatement quand des données sont supprimées, une baisse de performance se fait donc ressentir.

Est-ce vraiment gênant ? pas forcément.

Nous allons tester avec et sans le flag discard le temps d'extraction de l'archive linux-3.13.6.tar.xz (77,2 Mo) et le temps de suppression du contenu extrait (47854 éléments, totalisant 513,7 Mo).

Les commandes utilisées :

[root@local ~]$ time (tar Jxf linux-3.13.6.tar.xz; sync)
[root@local ~]$ time (rm -rf linux-3.13.6; sync)

Ce test sera réalisé 5 fois puis la moyenne sera calculée.

Avec mon SSD SanDisk SDSSDRC-032G-G26 ReadyCache 32 Go branché en SATA II sur un PC pas tout jeune (core 2 duo), voici les performances :

Avec le flag discard :

pass 1 extraction
real    0m16.289s
pass 1 suppression
real    0m1.979s
pass 2 extraction
real    0m15.385s
pass 2 suppression
real    0m1.873s
pass 3 extraction
real    0m15.334s
pass 3 suppression
real    0m1.864s
pass 4 extraction
real    0m15.425s
pass 4 suppression
real    0m2.036s
pass 5 extraction
real    0m15.436s
pass 5 suppression
real    0m1.813s

Sans le flag discard :

pass 1 extraction
real    0m16.488s
pass 1 suppression
real    0m1.500s
pass 2 extraction
real    0m15.132s
pass 2 suppression
real    0m1.487s
pass 3 extraction
real    0m14.942s
pass 3 suppression
real    0m1.383s
pass 4 extraction
real    0m16.265s
pass 4 suppression
real    0m1.360s
pass 5 extraction
real    0m15.731s
pass 5 suppression
real    0m1.355s

Et la moyenne :

Avec le flag discard :

  • extraction : 15.5738 = (16.289+15.385+15.334+15.425+15.436)/5
  • suppression : 1.913 = (1.979+1.873+1.864+2.036+1.813)/5

Sans le flag discard :

  • extraction : 15.7116 = (16.488+15.132+14.942+16.265+15.731)/5
  • suppression : 1.417 = (1.500+1.487+1.383+1.360+1.355)/5

La différence est assez ridicule pour mon cas, à vous de choisir votre méthode en fonction de votre utilisation.

10. Références et remerciements