Mauvaises performances d'écriture sur ecryptfs

J'ai fait un peu de benchmarking avec ecryptfs et dm-crypt, et j'ai obtenu des résultats intéressants. Tout ce qui suit a été fait avec un système de fichiers Btrfs, en utilisant ddpour copier un fichier de ~ 700 Mo vers / à partir d'un disque virtuel avec l' conv=fdatasyncoption pour forcer la synchronisation des données. Les caches de disque ont été effacées avant chaque test.

No encryption:
 read - 165MB/s
 write - 120MB/s
ecryptfs:
 read - 125MB/s
 write - 15MB/s
dm-crypt:
 read - 150MB/s
 write - 115MB/s
dm-crypt + ecryptfs:
 read - 120MB/s
 write - 15MB/s

Maintenant, je comprends que le cryptage est plus lent qu'un système de fichiers brut, mais je ne m'attendais pas à une baisse massive des performances d'écriture avec ecryptfs. Le fait de forcer la synchronisation des données rend-il ce test irréaliste? Ou existe-t-il des options que je peux transmettre à ecryptfs pour accélérer l'écriture?

J'utilisais le cryptage de nom de fichier sur ecryptfs, mais à part ça, tout était réglé par défaut.

La page de manuel ddabout about fdatasynclit:, physically write output file data before finishingdonc elle n'écrit les données physiquement "qu'une fois" (lisez-la comme "ne pas forcer un vidage tous les X blocs ou octets, mais un seul vidage à la fin"). Si vous utilisez ddpour faire vos tests, c'est le meilleur moyen d'obtenir les résultats les plus précis. Au contraire, ne pas utiliser cet indicateur spécifique rendrait vos résultats irréalistes: en omettant, il manquerait probablement le temps pour le cryptage lui-même car il ne dds'agit que de copier des données.

Néanmoins, je pensais également qu'il se passait quelque chose quant à vos résultats, mais j'ai trouvé cet article qui montre presque la même chose: ecryptfs est douloureusement lent. Et votre test ( un seul fichier en cours de copie) est le meilleur scénario pour ecryptfs!

Comme ecryptfs écrit un fichier chiffré (avec un en-tête personnalisé avec des métadonnées à l'intérieur) pour chaque version en texte clair, avoir beaucoup de petits fichiers implique une baisse de performances encore plus importante.

Cependant, ecryptfs a ses avantages: vous pouvez envoyer un fichier crypté immédiatement sans perdre le cryptage. Vos sauvegardes (en supposant que vous sauvegardez vos données cryptées ) seraient plus rapides car vous ne copieriez que des fichiers aussi volumineux que vos données (et encore plus vite si elles sont incrémentielles, car vous ne copieriez que des fichiers modifiés).

dm-crypt, d'autre part, peut être beaucoup plus rapide mais vous devrez envoyer le conteneur entier (un système de fichiers entier) pour garder le cryptage tel qu'il est. Et les sauvegardes consisteraient également en l'ensemble du conteneur, ne pouvant pas effectuer de sauvegardes incrémentielles dans la plupart des cas.

J'ai utilisé (et j'utilise toujours) les deux méthodes (mais pas les mêmes outils, cependant) pour conserver les données cryptées: basé sur des fichiers (ecryptfs) est plus facile à maintenir synchronisé via des services d'hébergement en ligne tels que dropbox entre PC, mais il est assez lent lorsque faire des changements et m'a causé quelques problèmes avec le système de fichiers sous-jacent (il suppose qu'il peut écrire les fichiers et les problèmes liés aux limites du système de fichiers ont tendance à casser le tout); Je préfère le cryptage de périphérique de bloc: je les traite comme de simples partitions, donc les limites et les problèmes ne se brisent pas si mal. Le seul inconvénient est de copier le conteneur, ce qui peut prendre beaucoup plus de temps.