GNU/Linux >> Tutoriels Linux >  >> Linux

Utilisation de TRIM et DISCARD avec des SSD connectés à des contrôleurs RAID

Les SSD sont désormais monnaie courante et ont été le choix par défaut pour les disques orientés performances dans les environnements d'entreprise et grand public au cours des dernières années. Les SSD sont cool et rapides, mais la plupart des utilisateurs de machines haut de gamme sont confrontés à ce dilemme :mon SSD est derrière un contrôleur RAID qui n'expose pas les capacités DISCARD ou TRIM de l'appareil. Comment supprimer les blocs pour conserver les meilleures performances SSD ? Voici une astuce pour y parvenir sans avoir à démonter votre machine. Les récentes améliorations du micrologiciel SSD ont rendu le besoin pour les applications écrivant sur les SSD moins contraignant d'utiliser DISCARD/TRIM.

Il existe cependant certains cas dans lesquels vous devrez peut-être demander au système de fichiers d'informer le lecteur des blocs qu'il a supprimés. Peut-être avez-vous des lecteurs TLC (3 bits par cellule) ou QLC (4 bits par cellule) au lieu des lecteurs SLC ou MLC de classe entreprise généralement plus chers (ces derniers sont moins sensibles à une baisse de performances car ils mettent de côté plus de blocs supplémentaires pour aider avec écrase lorsque le disque est à pleine capacité). Ou peut-être avez-vous déjà rempli votre SSD à 100 %, et maintenant vous ne pouvez plus récupérer les performances/IOPS d'origine.

Sur la plupart des systèmes, récupérer les performances est généralement une simple question d'édition d'un système de fichiers (fstrim ) commande. Voici un exemple utilisant un système Red Hat Enterprise Linux (RHEL) :

[root@System_A ~]# fstrim -av
/export/home: 130.5 GiB (140062863360 bytes) trimmed
/var: 26.1 GiB (28062511104 bytes) trimmed
/opt: 17.6 GiB (18832797696 bytes) trimmed
/export/shared: 31.6 GiB (33946275840 bytes) trimmed
/usr/local: 5.6 GiB (5959331840 bytes) trimmed
/boot: 678.6 MiB (711565312 bytes) trimmed
/usr: 36.2 GiB (38831017984 bytes) trimmed
/: 3 GiB (3197743104 bytes) trimmed
[root@System_A ~]#

[ Les lecteurs ont également aimé :Matériel Linux :Conversion en disques à semi-conducteurs (SSD) sur le bureau ]

Il y a un hic, cependant...

Si vos SSD se trouvent derrière un volume RAID connecté à un contrôleur RAID (SmartArray de HPE, PERC de Dell ou tout autre élément basé sur MegaRAID de LSI/Avago), voici ce qui se passe :

[root@System_B ~]# fstrim -av
[root@System_B ~]# 

Juste rien. Rien ne va se passer. À la fin de la chaîne d'E/S SCSI, les capacités d'un périphérique se résument au périphérique lui-même et au pilote RAID auquel votre disque est connecté.

Regardons de plus près. Voici un SSD (un disque Samsung EVO 860 2 To) connecté à un connecteur SATA sur un système RHEL (nous appellerons ce système System_A dans la suite de ce document) :

[root@System_A ~]# lsscsi 
[3:0:0:0]    disk    ATA      Samsung SSD 860  3B6Q  /dev/sda 

Voici un lecteur identique (même modèle, même micrologiciel) derrière un contrôleur RAID (un PERC H730P) sur un système différent (appelons ce système System_B dans la suite de ce document) :

[root@System_B ~]# lsscsi 
[0:2:0:0]    disk    DELL     PERC H730P Adp   4.30  /dev/sda 

Comment puis-je savoir que c'est le même lecteur ? Grâce à l'utilisation de megaclisas-status, le HBA RAID peut être interrogé. Cela montre ceci :

[root@System_B ~]# megaclisas-status
-- Controller information --
-- ID | H/W Model          | RAM    | Temp | BBU    | Firmware     
c0    | PERC H730P Adapter | 2048MB | 60C  | Good   | FW: 25.5.7.0005 

-- Array information --
-- ID | Type   |    Size |  Strpsz |   Flags | DskCache |   Status |  OS Path | CacheCade |InProgress   
c0u0  | RAID-0 |   1818G |  512 KB | ADRA,WB |  Enabled |  Optimal | /dev/sda | None      |None         

-- Disk information --
-- ID   | Type | Drive Model                                      | Size     | Status          | Speed    | Temp | Slot ID  | LSI ID  
c0u0p0  | SSD  | S3YUNB0KC09340D Samsung SSD 860 EVO 2TB RVT03B6Q | 1.818 TB | Online, Spun Up | 6.0Gb/s  | 23C  | [32:0]   | 0   

Oui, c'est le même lecteur (Samsung EVO 860) et le même firmware (3B6Q).

Utilisation de lsblk , nous allons exposer les fonctionnalités DISCARD de ces deux appareils :

[root@System_A ~]# lsblk -dD
NAME     DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda             0      512B       2G         1
[root@System_B ~]# lsblk -dD
NAME      DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda              0        0B       0B         0

Voici le coupable. Toutes les valeurs sont nulles. Le SSD dans un RAID 0 derrière un PERC H730P sur System_B n'expose aucune capacité DISCARD. C'est la raison pour laquelle fstrim sur System_B n'a rien fait ni rendu.

Les systèmes HPQ SmartArray sont affectés de la même manière. Voici un HPE DL360Gen10 avec une carte RAID SmartArray haut de gamme :

[root@dl360gen10 ~]# lsblk -dD
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda         0        0B       0B         0
sdc         0        0B       0B         0
sdd         0        0B       0B         0
sde         0        0B       0B         0
sdf         0        0B       0B         0
sdg         0        0B       0B         0
sdh         0        0B       0B         0

Tous basés sur LSI (megaraid_sas pilote) et les systèmes basés sur SmartArray (pilote hpsa) souffrent de ce problème. Si vous souhaitez TRIM vos SSD, vous devrez arrêter System_B , retirez le lecteur, connectez-le à un système compatible SAS/SATA et fstrim là.

Heureusement pour nous, il existe une petite astuce pour exposer temporairement les capacités natives de votre appareil et le TRIM. Cela nécessite de supprimer l'application qui utilise votre lecteur RAID, mais au moins cela ne vous oblige pas à vous rendre dans un centre de données pour extraire du matériel d'un système.

L'astuce consiste à arrêter d'utiliser le lecteur RAID via le pilote RAID, à exposer le SSD en tant que JBOD, à remonter le système de fichiers, puis à le COUPER. Une fois qu'il a supprimé les blocs, remettez simplement le lecteur en mode RAID, montez le système de fichiers, puis redémarrez vos applications.

Il y a quelques mises en garde :

  • Le matériel RAID que vous utilisez doit permettre aux appareils d'être mis en mode JBOD.
  • Vous ne pouvez pas le faire sur votre disque de démarrage, car cela nécessiterait d'arrêter le système d'exploitation.

Parcourir le processus

Voici une petite présentation créée sur un système avec un Dell PERC H730P et un SSD Samsung. Nous appellerons ce système System_C .

1) Le SSD est à [32:2] sur le HBA a0 , et nous allons créer un seul disque RAID 0 à partir de celui-ci :

[root@System_C ~]# MegaCli -CfgLdAdd -r0 [32:2] WB RA CACHED -strpsz 512 -a0

2) Le nouveau lecteur logique apparaît sous la forme /dev/sdd et n'affiche aucune fonctionnalité DISCARD :

[root@System_C ~]# lsblk -dD
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
[....]
sdd         0        0B       0B         0

3) Ensuite, créez un groupe de volumes (VG), un volume et un système de fichiers 128G sur ce périphérique :

[root@System_C ~]# parted /dev/sdd
[root@System_C ~]# pvcreate /dev/sdd1
[root@System_C ~]# vgcreate testdg /dev/sdd1
[root@System_C ~]# lvcreate -L 128G -n lv_test testdg
[root@System_C ~]# mount /dev/testdg/lv_test /mnt
[root@System_C ~]# mke2fs -t ext4 /dev/testdg/lv_test 
[root@System_C ~]# mount /dev/testdg/lv_test /mnt

Pour les besoins de cette démonstration, nous allons copier certaines données dans /mnt .

4) Arrêtez d'utiliser le système et exportez le groupe de volumes :

[root@System_C ~]# umount /mnt
[root@System_C ~]# vgchange -a n testdg
  0 logical volume(s) in volume group "testdg" now active
[root@System_C ~]# vgexport testdg
  Volume group "testdg" successfully exported

5) Activez le mode JBOD sur le HBA :

[root@System_C ~]# MegaCli -AdpSetProp -EnableJBOD -1 -a0

Adapter 0: Set JBOD to Enable success.

Exit Code: 0x00

6) Supprimez le lecteur logique et rendez le lecteur JBOD. Sur la plupart des contrôleurs RAID, les contrôles de sécurité vous empêchent de créer un JBOD avec un lecteur faisant partie d'un volume logique :

[root@System_C ~]# MegaCli -PDMakeJBOD -PhysDrv[32:2] -a0

Adapter: 0: Failed to change PD state at EnclId-32 SlotId-2.

Exit Code: 0x01

La solution ici est de supprimer le volume logique. Il s'agit d'une opération logique simple, et cela ne touchera pas nos données. Cependant, vous devez avoir écrit la commande utilisée pour créer la matrice RAID 0 en premier lieu.

[root@System_C ~]# MegaCli -CfgLdDel -L3 -a0
                                     
Adapter 0: Deleted Virtual Drive-3(target id-3)

Exit Code: 0x00
[root@System_C ~]# MegaCli -PDMakeJBOD -PhysDrv[32:2] -a0
                                     
Adapter: 0: EnclId-32 SlotId-2 state changed to JBOD.

Exit Code: 0x00

7) Actualisez la vue des disques du noyau et importez vos données :

[root@System_C ~]# partprobe
[root@System_C ~]# vgscan 
  Reading volume groups from cache.
  Found exported volume group "testdg" using metadata type lvm2
  Found volume group "rootdg" using metadata type lvm2

[root@System_C ~]# vgimport testdg
  Volume group "testdg" successfully imported

[root@System_C ~]# vgchange -a y testdg
  1 logical volume(s) in volume group "testdg" now active

[root@System_C ~]# mount /dev/testdg/lv_test /mnt

[root@System_C ~]# fstrim -v /mnt
/mnt: 125.5 GiB (134734139392 bytes) trimmed

Nous avons supprimé les blocs vides de notre système de fichiers. Remettons-le dans un lecteur logique RAID 0.

8) umount le système de fichiers et exportez le groupe de volumes :

[root@System_C ~]# umount /mnt
[root@System_C ~]# vgchange -a n testdg
  0 logical volume(s) in volume group "testdg" now active
[root@System_C ~]# vgexport testdg
  Volume group "testdg" successfully exported

9) Désactivez le mode JBOD sur le contrôleur RAID :

[root@System_C ~]# MegaCli -AdpSetProp -EnableJBOD -0 -a0

Adapter 0: Set JBOD to Disable success.

Exit Code: 0x00

10) Recréez votre lecteur logique :

[root@System_C ~]# MegaCli -CfgLdAdd -r0 [32:2] WB RA CACHED -strpsz 512 -a0

11) Demandez au noyau de tester les disques et de remonter votre système de fichiers :

[root@System_C ~]# partprobe
[root@System_C ~]# vgscan 
  Reading volume groups from cache.
  Found exported volume group "testdg" using metadata type lvm2
  Found volume group "rootdg" using metadata type lvm2

[root@System_C ~]# vgimport testdg
  Volume group "testdg" successfully imported

[root@System_C ~]# vgchange -a y testdg
  1 logical volume(s) in volume group "testdg" now active

[root@System_C ~]# mount /dev/testdg/lv_test /mnt

Vos données devraient être là et les performances de votre SSD devraient être revenues à leurs chiffres d'origine.

[ Cours en ligne gratuit :Présentation technique de Red Hat Enterprise Linux. ] 

Conclusion

Voici quelques remarques supplémentaires :

  • Cette procédure doit être prise avec un grain de sel et avec un gros avertissement :NE PAS effectuer cette opération à moins d'être sûr de pouvoir identifier les lecteurs logiques et les JBOD sur un système Linux.
  • Je n'ai testé cette procédure qu'avec des disques logiques RAID 0. Il semble peu probable qu'il fonctionne pour d'autres types de RAID (5, 6, 1+0, etc.) car la structure du système de fichiers sera cachée du système d'exploitation Linux.
  • Veuillez ne pas effectuer cette procédure sans sauvegardes vérifiées.

Linux
  1. Trucs et astuces pour utiliser CUPS pour imprimer avec Linux

  2. Activer TRIM pour SSD sous Linux

  3. Couper avec Lvm et Dm-crypt ?

  4. rechercher et supprimer des fichiers avec de l'espace à l'aide de la commande find sous Linux

  5. Comment remplir un fichier avec FF en utilisant dd ?

Planifier des travaux sous Linux avec la commande 'at'

Comment :Programmation orientée objet - Plus avec les classes et les objets

Comment déployer une application PHP avec Nginx et MySQL à l'aide de Docker et Docker Compose

Utilisation de Tailscale sur Windows pour réseauter plus facilement avec WSL2 et Visual Studio Code

Problèmes d'utilisation du tri et de la communication

Possible de faire fonctionner SSD TRIM (jeter) sur ext4 + LVM + RAID logiciel sous Linux ?