Comment ecryptfs a-t-il un impact sur les performances du disque dur?
J'ai ma maison directement cryptée avec ecryptfs. Ecryptfs mène-t-il à la fragmentation?
J'ai l'impression que lire des fichiers, afficher des dossiers et se connecter devient de plus en plus lent (bien que ce ne soit pas lent au début). Le disque dur fait beaucoup de bruit même si je n’ouvre que des fichiers texte. Dans /home/.ecryptfs, je vois beaucoup d’archives volumineuses (qui contiennent probablement les fichiers chiffrés). Je me demande donc si la défragmentation en ligne du système de fichiers Linux gagne quelque chose ici.
Quelles sont les options pour augmenter les performances? Devrais-je décider si je ferais peut-être mieux sans cryptage?
Phoronix a exécuté une suite de tests et quelques articles sur les performances de eCryptfs lors du chiffrement de répertoires de départ:
- http://www.phoronix.com/scan.php?page=article&item=ubuntu_910_encryption&num=1
- http://www.phoronix.com/scan.php?page=article&item=ubuntu_jaunty_encrypt&num=1
Ce que je retiens de ces articles, c'est que le chiffrement (comme prévu) selon les tests de performance a un impact sur les performances de lecture et d'écriture dans une certaine mesure. Ceci est peut-être plus évident sur les petits processeurs (processeurs Atom) et sur les disques durs rapides (SSD). Cela dit, en utilisant eCryptfs, vous ne payez que cette pénalité de performance lorsque vous lisez/écrivez des données dans votre répertoire personnel (et non le reste du système, comme vous le feriez avec le chiffrement de disque complet). De plus, avec les processeurs plus rapides, le temps passé à effectuer le cryptage/décryptage correspond souvent à l'attente IO d'accéder aux données à partir du disque, qui constitue généralement le goulot d'étranglement.
En ce qui concerne votre problème particulier, si vous entendez beaucoup de "recherche de disque dur", il me semble que votre système échange des données de la mémoire sur le disque, et inversement. Si vous avez choisi d'utiliser eCryptfs, Ubuntu chiffrera automatiquement votre espace d'échange (nécessaire pour protéger vos données cryptées). Cependant, le swap crypté est également très coûteux.
Personnellement, je surcharge mes systèmes avec beaucoup de RAM (8 Go sur la plupart de mes systèmes) et désactive totalement l'échange.
Je programme avec python dans mon répertoire personnel et j'ai un environnement virtuel Python pour les packages de projet.
Pour mes programmes, les temps de démarrage sont beaucoup plus lents sur eCryptfs, car Python émet de nombreux appels système stat () lors de la recherche de fichiers de module; comme beaucoup de ces appels de statistiques aboutissent à un "fichier non trouvé", et que ces résultats ne sont jamais mis en cache, mais que nous payons toujours une pénalité pour les ecryptfs, les choses sont toujours lentes.
Mise à jour
J'ai fini par retirer ecryptfs de mon répertoire personnel en déplaçant le point de montage ecryptfs vers ~/private, en copiant la plupart des fichiers du répertoire ~/private dans mon dossier personnel non chiffré. Les choses sont maintenant rapides à nouveau. Peut-être que la pénalité de performance serait moindre pour un autre processeur, j'ai un Asus 1215N avec Atom.
Je n'ai pas fait de mesures de noyau dur, alors prenez les mesures suivantes avec un grain de sel, mais j'ai constaté des performances extrêmement médiocres avec ecryptfs dans les scénarios suivants par rapport à un LV dm-crypt'd (monté en tant que/home/nom d'utilisateur):
du sur un dossier avec beaucoup de fichiers. Cela prend plusieurs minutes alors que quelques secondes seulement utilisent dm-crypt de la partition entière - c’est de loin le pire des cas.
l’ouverture d’un dossier contenant beaucoup d’éléments dans mutt prend plusieurs secondes (environ 20 sur un dossier contenant 10 000 éléments) alors que cela est presque instantané avec dm-crypt
les opérations git sont plus lentes (par certains, pas beaucoup) par rapport à dm-crypt
des applications telles que Firefox prennent beaucoup plus de temps à démarrer, mais nous sommes toujours dans la plage des secondes.
Je viens de passer à dm-crypt (avec pam_mount) et je ne pourrais être plus heureux!
les appels tels que truncate () et ftruncate () qui augmentent la taille du fichier sont plus lents sur ecryptfs car ils doivent se remplir de zéros cryptés, contrairement aux systèmes de fichiers normaux qui ne font que créer des trous dans le fichier.