vérifier indépendamment que TRIM fonctionne bien sur SSD

13

J'ai une LUKSpartition avec /dev/sda1laquelle je luksOpen --allow-discards:

cryptsetup --allow-discards luksOpen /dev/sda1 root

Je monte ensuite le ext4système de fichiers avec l' discardoption:

grep /dev/mapper/root /proc/mounts
/dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0

Je coupe ensuite l'espace libre sur la partition montée:

fstrim -v /

avec df, je vois /a 80% d'espace libre. Cela signifie que sur /dev/sda180% du disque sont des zéros binaires.

Si je clone l'image avec cat

cat /dev/sda1 > sda1.img

et compresser l'image avec xz, je m'attendrais à ce que tous les zéros du disque soient compressés. Étant donné que les 20% des données sur le disque sont cryptées, elles devraient ressembler à des données aléatoires et être incompressibles. Par conséquent, l'image compressée xz doit être approximative. 20% de la taille brute.

Cependant, l'image compressée xz résultante a approximativement la même taille que l'original brut.

Mon raisonnement est-il correct?

Pourquoi ma théorie ne se traduit-elle pas en pratique?

ext4 ssd cryptsetup trim fstrim Martin Vegter
la source
2
unix.stackexchange.com/a/85880/30851 et aussidmsetup table | grep allow_discards
frostschutz

Réponses:

8

Votre logique n'est pas incorrecte. Mais il n'est valable que si certaines conditions sont remplies.

La commande TRIM , comme spécifié dans le jeu de commandes ATA , peut ou non mettre à zéro les secteurs pour lesquels elle est émise.
En fait, la norme se concentre sur les données à retourner après la publication de TRIM 1 :

Les comportements suivants sont spécifiés par cette norme pour les secteurs que l'appareil coupe (voir 7.5.3.3):

a) non déterministe - les données en réponse à une lecture d'un secteur coupé peuvent changer pour chaque lecture jusqu'à ce que le secteur soit écrit par l'hôte;
b) Lecture déterministe après découpage (DRAT) - les données renvoyées en réponse à la lecture d'un secteur découpé ne changent pas, mais peuvent être différentes de celles qui ont été précédemment renvoyées; et
c) Lire les zéros après ajustement (RZAT) - les données renvoyées en réponse à une lecture du secteur ajusté sont nulles.

[...] Pour les périphériques de stockage DRAT et non déterministes, les données renvoyées en réponse à une commande de lecture à un LBA qui a été correctement coupé:

a) peut être les données précédemment renvoyées pour le LBA spécifié;
b) peut être un motif généré par le dispositif de stockage; et
c) ne sont pas des données précédemment écrites sur un LBA différent par l'hôte.

Ainsi, ce que votre appareil retourne après fstrimdépend des fonctionnalités qu'il implémente. À moins qu'il ne prenne en charge RZAT, l'hypothèse selon laquelle les données lues à partir d'un périphérique découpé seront uniquement des zéros ne tient pas.

Vous pouvez utiliser hdparmpour vérifier cela:

sudo hdparm -I /dev/sdX | grep -i trim

J'ai effectué quelques tests en utilisant deux SSD, sdaet sdb. Même fabricant, différents modèles, avec une conformité ATA différente:

$ sudo hdparm -i /dev/sdb
 ...
 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7
 ...

$ sudo hdparm -i /dev/sda
 ...
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7
 ...

Les deux SSD ont un support différent pour TRIM:

$ sudo hdparm -I /dev/sda | grep -i trim
           *    Data Set Management TRIM supported (limit 1 block)

$ sudo hdparm -I /dev/sdb | grep -i trim
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

Je peux confirmer qu'après la publication fstrim, le lecteur prenant en charge les "Zéros de lecture déterministes après TRIM" (RZAT) semble avoir mis à zéro la partition concernée presque entièrement. Inversement, l'autre lecteur semble avoir mis à zéro (ou autrement remplacé par un modèle hautement compressible) seulement une partie mineure de l'espace libéré.

1 Source en ligne: INCITS 529: Technologies de l'information - Jeu de commandes ATA / ATAPI - 4 (ACS-4)

Remarque sur les tests:

Comme l'a souligné frostschutz dans les commentaires, une lecture après fstrimpeut renvoyer des données à partir du cache du système d'exploitation, et non à partir du périphérique coupé. C'est, par exemple, ce qui s'est passé dans cette qustion .
(Je voudrais également souligner cette réponse à la même question pour une méthode alternative pour tester TRIM).

Entre fstrimet une lecture ultérieure, vous devrez peut-être supprimer le cache, par exemple avec:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Selon la taille de la partition avec laquelle vous jouez, ne pas supprimer le cache peut suffire à l'échec de vos tests.

Remarque sur votre configuration:

L' discardoption de montage permet un TRIM continu, c'est-à-dire à tout moment où les fichiers sont supprimés. Il n'est pas requis par fstrim. En effet, le TRIM à la demande et le TRIM continu sont deux façons distinctes de gérer les opérations de TRIM. Pour plus d'informations, je voudrais indiquer Solid State Drive sur le Wiki Arch Linux, qui a une couverture détaillée de cette question.

fra-san
la source
Linux pourrait également renvoyer des données non nulles de son cache après TRIM, même si le SSD les relirait sous forme de zéros. C'était un problème avec mon oui-trim-test là-bas unix.stackexchange.com/a/85880/30851 mais pourrait également être lié à la lecture des données brutes avant et après TRIM. Donc, si vous n'obtenez pas zéro lorsque vous vous y attendez, supprimez les caches au cas où.
frostschutz
@frostschutz Bon point! Je supposais en quelque sorte que, puisque l'OP mentionnait un volume "racine", il aurait été trop gros pour qu'une partie significative de celui-ci puisse tenir en mémoire. Mais il est certain que le cache était sur mon chemin pendant mes tests - qui a lamentablement échoué jusqu'à ce que je commence à le supprimer. Je mettrai à jour ma réponse.
fra-san
2

Le SSD a-t-il une couche de chiffrement matériel intégrée? S'il en a un, alors les blocs TRIMmed peuvent être tous des zéros (ou peut-être tous) au niveau du matériel brut, mais puisque l'ordinateur les voit à travers la couche de cryptage, ils apparaîtront comme du charabia pseudo-aléatoire après avoir passé le tout -Zéro bloque le bloc à travers le processus de décryptage.

Une telle couche de chiffrement matériel aurait certains avantages:

  • Cela permettrait une fonctionnalité d'effacement de sécurité très rapide: il suffit que le lecteur détruise la clé d'origine utilisée dans la couche de cryptage matériel et la remplace par une nouvelle et toutes les données seront instantanément irrécupérables pour la plupart des applications pratiques.
  • Étant donné que toutes les données atteignant le niveau matériel brut seraient cryptées, il serait garanti qu'elles semblent pseudo-aléatoires et donc largement homogènes. Cela pourrait aider à éviter les points chauds / froids et à simplifier considérablement l'estimation de l'usure.
telcoM
la source
0

df signaler un espace libre n'implique pas un espace mis à zéro.

trimindique au périphérique de stockage que les blocs ne sont pas utilisés. Je ne pense pas que cela les zéros.

ctrl-alt-delor
la source