Quelle est la charge de performance de crypté / home?

32

J'ai un netbook avec Windows sur la deuxième partition et Xubuntu ( / et /home ) sur la troisième partition. J'ai choisi de chiffrer mon dossier personnel lors de l'installation. Les performances du netbook sont adaptées à la petite machine, mais je cherche à améliorer les performances. Je n'ai pas trouvé beaucoup d'informations sur le surcoût (CPU ou lecteur) associé au chiffrement de la partition domestique. J'ai exécuté ce qui suit en écrivant sur ma partition personnelle ainsi que sur la partition Windows montée:

dd if=/dev/zero of=~/dummy bs=512 count=10240

dd if=/dev/zero of=/media/Windows/dummy bs=512 count=10240

Le premier retourne 2,4 Mo / s et le second renvoie 2,5 Mo / s. Puis-je en déduire qu'il y a très peu de surcharge au chiffrement du dossier de départ? Je ne sais pas si les différents systèmes de fichiers feront la moindre différence ( / et /home sont ext3).

Mise à jour 1

Je ne sais pas pourquoi je n'ai pas utilisé /tmp au lieu du dossier Windows monté. Seul /home est chiffré, donc /tmp est ext3 non chiffré. Les résultats du dd comme ci-dessus sont stupéfiants:

~ : 2,4 Mo / s

/tmp : 42,6 Mo / s

Commentaires s'il vous plaît? La raison pour laquelle je pose cette question est que l’accès au disque dur sur le netbook est très lent.

Mise à jour 2

J'ai chronométré chacune des opérations dd avec time :

~ :

real    0m2.217s  
user    0m0.028s  
sys     0m2.176s

/tmp :

real    0m0.152s  
user    0m0.012s  
sys     0m0.136s

Voir aussi: discussion sur UbuntuForums.org et rapport de bogue (2012/05/11: semble maintenant être un bogue relatif aux SSD)

Modifier: sortie de mount :

/dev/sda3 on / type ext3 (rw,noatime,errors=remount-ro,user_xattr,commit=600)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/USER/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=USER)

Mise à jour 01/05/2012: Autres liens associés pour référence: un (ancien) Phoronix test , un question similaire ici, une question dupliquer ici et une question similaire . Une bonne réponse récapitulative ici suggère que les pénalités de performance ne sont visibles que sur les petits processeurs et les netbooks (Atom) et les SSD.

    
posée SabreWolfy 27.01.2011 - 09:31
la source

4 réponses

15

J'utilise la fonctionnalité de répertoire personnel crypté depuis des années et je peux vous dire que même si cela se comporte normalement dans des circonstances normales, cela mettra votre machine à genoux lors d'opérations de fichiers intenses.

J'ai un Pentium i7 quad-core avec 16 Go de RAM de System7. À tous égards, il s’agit d’un ordinateur portable ultrarapide doté d’un lecteur SATA 7200 RPM. Juste aujourd'hui, lorsque je décompressais un fichier contenant 20 000 petits fichiers texte (10 minutes), mon système est essentiellement inutilisable. Tout ce qui touche au système de fichiers a un délai de 1 à 2 secondes, y compris le navigateur Web. Mon expérience est exactement celle de l'OP - le répertoire personnel crypté est environ 15 fois plus lent que le répertoire non crypté.

Je n'y pensais pas car je suis tellement habitué (c'est mon 4ème ordinateur portable). Par chance, si quelqu'un a une astuce pour l'améliorer, j'ai pensé que je chercherais ici.

Je crypte mon répertoire personnel parce que je dois le faire. Si vous n'avez pas à ... alors ne le faites pas.

    
réponse donnée HDave 11.02.2014 - 21:03
la source
9

dd n'est PAS un bon moyen de mesurer les performances HD. Il y a pour beaucoup de variables impliquées et tout bon test devrait être fait de nombreuses fois de toute façon.

Le chiffrement génère un surcoût, en particulier sur les processeurs "moindres" présents dans les netbooks. Ils sont moins chers pour une raison après tout.

Bien que je n’aie pas de données sur le chiffrement de lecteur, j’ai fait des tests sur https vs http pour un serveur Web et le coût est considérable, mais pas mortel. Cependant, votre répertoire d'accueil a tendance à être un gâchis avec les programmes écrivant au hasard dans leurs répertoires cachés. Voir Firefox pour un mauvais garçon à cet égard. Ceci est un léger ralentissement constant sur un netbook qui est déjà plus lent et souvent en standard avec une HD lente.

Exécuter à nouveau avec bonnie ++ un autre utilisateur recommandé, mais cette fois, faites-le avec deux utilisateurs différents, l'un avec un HD crypté, l'autre sans. Assurez-vous que les deux répertoires sont remplis de la même manière.

Cela vous donne un test beaucoup plus précis. Je ne serais pas surpris de voir une performance d'environ 20% ou plus. C’est ce que mon serveur Web a fait quand on lui a demandé de chiffrer tout ce qu’il émettait. Et vous lisez et écrivez des données chiffrées.

    
réponse donnée Didier 28.02.2011 - 22:22
la source
3

Bien que le cryptage apportera certainement une surcharge, le cryptage de la partition d’accueil ne devrait pas avoir d’impact important sur les performances de votre système. La plupart des programmes que vous exécutez sont lus brom / bin ou / usr et la plupart des écritures système sont dans / var ou / tmp.

Seuls vos fichiers d’utilisateur se trouvent dans / home, vous aurez donc un impact sur le traitement de fichiers volumineux, que je mets généralement sur une partition distincte, conservant ma place uniquement pour les documents.

    
réponse donnée Sunny 25.02.2011 - 19:22
la source
0

La vitesse de transfert est loin d'être suffisante pour évaluer le surcoût du chiffrement: il se pourrait que le goulot d'étranglement soit la capacité d'E / S de votre disque dur. Vous voudrez peut-être également examiner l’utilisation du processeur, cela pourrait (ou non) être différent, que vous utilisiez ou non le chiffrement.

    
réponse donnée user9521 27.01.2011 - 14:12
la source

Lire d'autres questions sur les étiquettes