web-dev-qa-db-fra.com

Comment vérifier si TRIM fonctionne pour un volume chiffré?

Vous pouvez facilement vérifier si TRIM fonctionne pour une partition ext4 "normale": https://askubuntu.com/a/19480/592 .

Comment faire cela pour un système crypté par LUKS? Supposons que la configuration par défaut de LUKS effectuée par 12.04 Un autre installateur (c’est-à-dire celui avec LVM impliqué).

Mise à jour

Ce que je demande ici, c'est comment je peux vérifier que le bloc sur le disque est réellement rempli de zéros après la suppression du fichier, si le fichier est stocké dans un volume crypté.

12.04ssdlukstrim
6
Tomasz Zieliński

Je n'ai pas encore dm-crypt avec la configuration TRIM, mais je voudrais aussi vérifier. Tout d'abord, il faut savoir que cela pourrait ne pas être possible, en fonction de votre SSD (voir: https://serverfault.com/a/401506/60525 ).

En supposant que vous ayez le bon type de SSD, je vois deux options différentes:

  1. Testez ceci sur un très petit périphérique de bloc. Créez une partition cryptée de 20 Mo exactement comme vous le feriez pour tout votre système. Assurez-vous de remplir d'abord la partition avec des octets aléatoires. Ensuite, créez, écrivez, videz et supprimez un fichier de 10 Mo sur le fs chiffré. Exécutez fstrim sur le fs monté. Si tout fonctionne, vous devriez voir environ la moitié de la partition de 20 Mo remplie avec zéro octet.

  2. Vous pouvez également vérifier que la commande UNMAP ou WRITE SAME scsi est émise via le sous-système scsi. Le seul moyen que j’ai trouvé de voir les paquets scsi sans utiliser de périphérique matériel ni de piratage du noyau était d’allumer enregistrement des paquets scsi :

    echo $ BITMASK>/sys/module/scsi_mod/parameters/scsi_logging_level

    Utiliser 9216 comme BITMASK me suffisait pour voir que les cdbs WRITE SAME étaient envoyés après le fstrim d’un fs ext4 résidant directement sur le disque (pas de cryptage).

    Vous pouvez utiliser soit fstrim au niveau fs, soit sg_unmap/sg_write_same au niveau périphérique pour déclencher un TRIM. Une fois que vous avez trouvé UNMAP ou WRITE SAME, utilisez les documents scsi de t10.org pour décoder le paquet et déterminer le bloc de disque auquel il fait référence. Ensuite, vérifiez que le disque contient des zéros dans ce (s) secteur (s).

Cette dernière approche est plus ardue, mais elle présente l’avantage de travailler sur des installations préexistantes et est beaucoup plus facile lorsque vous travaillez avec des systèmes de fichiers de taille non triviale. Vous jugerez peut-être suffisant que la commande UNMAP ou WRITE SAME soit envoyée (vous souciez-vous vraiment de la présence de zéros ou non?) Notez que cette dernière approche ne fonctionnera probablement pas si TRIM est exécuté via la commande ata DATA SET MANAGEMENT, il ne devrait pas apparaître dans le journal scsi et je ne vois pas comment obtenir des cdbs ata. Mais je parie que c'est moins de .01% des cas.

Cette dernière solution pourrait être quelque chose d'automatisé, ainsi nous n'aurions pas à décoder le paquet à la main. N'importe quels preneurs?

Et pour autant que je sache maintenant, il n’ya aucun moyen d’obtenir une correspondance entre l’adresse de bloc cryptée et l’adresse de bloc du périphérique sans piratage de dm-crypt.c. Si vous bloquez la carte de l’appareil à zéro secteur sur l’appareil, vous vous retrouverez dans un monde de douleur.

2
crass

Ceci a été répondu à la question que vous avez liée.

Si vous utilisez LVM, vous devez ajouter discard aux options de /etc/fstab.

Ouvrez /etc/fstab avec n’importe quel éditeur

# Command line
Sudo -e /etc/fstab

# Graphical
gksu gedit /etc/fstab

Ajouter dans "rejeter" aux options de la 4ème colonne.

/dev/mapper/volumegroup-root  /  ext4  discard,noatime,nodiratime,errors=remount-ro  0  1

Vous ajoutez ensuite dans la même option (ignorer) à /etc/crypttab

En supposant que votre partition LUKS est /dev/sda1 (ajustez en conséquence)

# Command line
Sudo -e /etc/crypttab

# Graphical
gksu gedit /etc/crypttab

Encore une fois, ajoutez dans la défausse:

sda1_crypt UUID=[... series of numbers ...] none luks,discard

Mettez à jour vos initramfs

Sudo update-initramfs -c -k all

Redémarrer

Confirmez que TRIM fonctionne ...

Sudo dmsetup table /dev/mapper/sda1_crypt --showkeys

Vous devriez voir "allow_discards" dans la sortie

Pour plus d'informations, voir: http://worldsmostsecret.blogspot.com/2012/04/how-to-activate-trim-on-luks-encrypted.html

1
Panther

Je ne vois pas comment TRIM peut fonctionner du tout pour un volume chiffré; le volume est, par définition, plein de données aléatoires (c'est-à-dire non nulles). TRIM met à zéro les blocs lorsque le système de fichiers ne contient plus de données actives stockées. Dans un volume chiffré, ce qui est stocké sur le périphérique de bloc matériel n'est pas un système de fichiers, mais un périphérique de bloc virtuel.

0
Adrian