Gli SSD sono ormai all'ordine del giorno e negli ultimi anni sono stati la scelta predefinita per i dischi orientati alle prestazioni negli ambienti aziendali e consumer. Gli SSD sono fantastici e veloci, ma la maggior parte delle persone su macchine di fascia alta affronta questo dilemma:il mio SSD si trova dietro un controller RAID che non espone le capacità DISCARD o TRIM del dispositivo. Come faccio a eliminare i blocchi per mantenere le migliori prestazioni dell'SSD? Ecco un trucco per farlo senza dover smontare la macchina. I recenti miglioramenti del firmware SSD hanno reso la necessità per le applicazioni di scrittura su SSD meno stringente per l'utilizzo di DISCARD/TRIM.
Ci sono, tuttavia, alcuni casi in cui potrebbe essere necessario che il filesystem informi l'unità dei blocchi che ha scartato. Forse hai unità TLC (3 bit per cella) o QLC (4 bit per cella) invece delle unità SLC o MLC di classe enterprise solitamente più costose (queste ultime sono meno suscettibili a un calo delle prestazioni poiché mettono da parte più blocchi extra per aiutare con sovrascrive quando l'unità è a capacità). O forse una volta hai riempito il tuo SSD al 100% e ora non puoi recuperare le prestazioni/IOPS originali.
Sulla maggior parte dei sistemi, ripristinare le prestazioni è solitamente una semplice questione di emettere un taglio del filesystem (fstrim ) comando. Ecco un esempio che utilizza un sistema 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 ~]# [ Ai lettori è piaciuto anche:Hardware Linux:conversione in dischi a stato solido (SSD) sul desktop ]
C'è un problema, però...
Se i tuoi SSD sono dietro un volume RAID collegato a un controller RAID (SmartArray di HPE, PERC di Dell o qualsiasi cosa basata su LSI/MegaRAID di Avago), ecco cosa succede:
[root@System_B ~]# fstrim -av
[root@System_B ~]# Proprio niente. Non succederà nulla. Alla fine della catena di I/O SCSI, le capacità di un dispositivo si riducono al dispositivo stesso e al driver RAID a cui è collegata l'unità.
Diamo un'occhiata più da vicino. Ecco un SSD (un'unità Samsung EVO 860 2Tb) collegato a un connettore SATA su un sistema RHEL (chiameremo quel sistema System_A nel resto di questo documento):
[root@System_A ~]# lsscsi
[3:0:0:0] disk ATA Samsung SSD 860 3B6Q /dev/sda Ecco un'unità identica (stesso modello, stesso firmware) dietro un controller RAID (un PERC H730P) su un sistema diverso (chiamiamolo Sistema_B nel resto di questo documento):
[root@System_B ~]# lsscsi
[0:2:0:0] disk DELL PERC H730P Adp 4.30 /dev/sda
Come faccio a sapere che è la stessa unità? Grazie all'uso di megaclisas-status, è possibile interrogare l'HBA RAID. Mostra questo:
[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 Sì, è la stessa unità (Samsung EVO 860) e lo stesso firmware (3B6Q).
Usando lsblk , esporremo le funzionalità DISCARD di questi due dispositivi:
[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
Ecco il colpevole. Tutti i valori sono zero. L'SSD in un RAID 0 dietro un PERC H730P su System_B non espone alcuna capacità di DISCARD. Questo è il motivo per cui fstrim su Sistema_B non ha fatto o restituito nulla.
I sistemi HPQ SmartArray sono interessati in modo simile. Ecco un HPE DL360Gen10 con una scheda RAID SmartArray di fascia alta:
[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
Tutti basati su LSI (megaraid_sas driver) e i sistemi basati su SmartArray (driver hpsa) soffrono di questo problema. Se desideri TRIM i tuoi SSD, dovresti spegnere System_B , estrai l'unità, collegala a un sistema compatibile con SAS/SATA e fstrim lì.
Fortunatamente per noi, c'è un piccolo trucco per esporre temporaneamente le capacità native del tuo dispositivo e TAGLIArlo. Ciò richiede la rimozione dell'applicazione che utilizza l'unità RAID, ma almeno non è necessario recarsi a un DataCenter per estrarre dell'hardware da un sistema.
Il trucco è smettere di usare l'unità RAID tramite il driver RAID, esporre l'SSD come un JBOD, rimontare il filesystem e quindi TRIMlo lì. Una volta che ha eliminato i blocchi, rimetti semplicemente l'unità in modalità RAID, monta il filesystem e quindi riavvia le applicazioni.
Ci sono un paio di avvertimenti:
- L'hardware RAID in uso deve consentire ai dispositivi di essere messi in modalità JBOD.
- Non è possibile eseguire questa operazione sul disco di avvio poiché richiederebbe la rimozione del sistema operativo.
Camminando attraverso il processo
Ecco una piccola guida dettagliata creata su un sistema con un Dell PERC H730P e un SSD Samsung. Chiameremo questo sistema Sistema_C .
1) L'SSD è a [32:2] su HBA a0 e creeremo una singola unità RAID 0 da essa:
[root@System_C ~]# MegaCli -CfgLdAdd -r0 [32:2] WB RA CACHED -strpsz 512 -a0
2) La nuova unità logica si apre come /dev/sdd e non mostra alcuna capacità di DISCARD:
[root@System_C ~]# lsblk -dD
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
[....]
sdd 0 0B 0B 0 3) Quindi, crea un gruppo di volumi (VG), un volume e un filesystem 128G sopra quel dispositivo:
[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
Per il bene di questa dimostrazione, copieremo alcuni dati in /mnt .
4) Smetti di usare il sistema ed esporta il gruppo di volumi:
[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) Abilita la modalità JBOD sull'HBA:
[root@System_C ~]# MegaCli -AdpSetProp -EnableJBOD -1 -a0
Adapter 0: Set JBOD to Enable success.
Exit Code: 0x00 6) Eliminare l'unità logica e rendere l'unità JBOD. Sulla maggior parte dei controller RAID, i controlli di sicurezza impediscono di creare un JBOD con un'unità che fa parte di un volume logico:
[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 soluzione qui è eliminare il volume logico. Questa è una semplice operazione logica e non toccherà i nostri dati. Tuttavia, devi prima aver annotato il comando utilizzato per creare l'array RAID 0.
[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) Aggiorna la visualizzazione dei dischi del kernel e importa i tuoi dati:
[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 Abbiamo scartato i blocchi vuoti sul nostro filesystem. Rimettiamolo in un'unità logica RAID 0.
8) umount il filesystem ed esportare il gruppo di volumi:
[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) Disabilita la modalità JBOD sul controller RAID:
[root@System_C ~]# MegaCli -AdpSetProp -EnableJBOD -0 -a0
Adapter 0: Set JBOD to Disable success.
Exit Code: 0x00 10) Ricrea la tua unità logica:
[root@System_C ~]# MegaCli -CfgLdAdd -r0 [32:2] WB RA CACHED -strpsz 512 -a0 11) Chiedi al kernel di sondare i dischi e rimontare il tuo filesystem:
[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 I tuoi dati dovrebbero essere lì e le prestazioni del tuo SSD dovrebbero tornare ai valori originali.
[ Corso online gratuito:panoramica tecnica di Red Hat Enterprise Linux. ]
Conclusione
Ecco alcune note aggiuntive:
- Questa procedura dovrebbe essere presa con le pinze e con un grande avvertimento:NON eseguirlo a meno che tu non sia sicuro di poter identificare unità logiche e JBOD su un sistema Linux.
- Ho testato questa procedura solo utilizzando unità logiche RAID 0. Sembra improbabile che funzioni per altri tipi di RAID (5, 6, 1+0, ecc.) poiché la struttura del filesystem sarà nascosta dal sistema operativo Linux.
- Non eseguire questa procedura senza backup verificati.