Tengo mi casa directamente encriptada con ecryptfs. ¿Ecryptfs conduce a la fragmentación?
Tengo la sensación de que la lectura de archivos, la visualización de carpetas y el inicio de sesión se hizo cada vez más lento (aunque no fue notablemente lento al principio). El disco duro hace mucho ruido de búsqueda incluso si abro solo un archivo de texto. En /home/.ecryptfs veo muchos archivos grandes (que probablemente contienen los archivos cifrados), así que me pregunto si la desfragmentación en línea del sistema de archivos de Linux gana algo aquí.
¿Qué opciones tengo para aumentar el rendimiento? ¿Debo decidir si puedo hacerlo mejor sin cifrado?
filesystem
performance
ecryptfs
defrag
Freddi
fuente
fuente
Respuestas:
Phoronix ha ejecutado un conjunto de pruebas y un par de artículos sobre el rendimiento de eCryptfs al cifrar directorios de inicio:
Lo que me quito de esos artículos es que el cifrado (como se esperaba) de acuerdo con los puntos de referencia, afecta en cierta medida el rendimiento de lectura y escritura. En CPU pequeñas (procesadores Atom) y en discos duros rápidos (SSD), esto es quizás más notable. Dicho esto, al usar eCryptfs, solo paga esa penalización de rendimiento al leer / escribir datos en su directorio de inicio (y no en el resto del sistema, como lo haría con el cifrado de disco completo). Además, con procesadores más rápidos, la cantidad de tiempo que se dedica a realizar ese cifrado / descifrado a menudo se ajusta a la espera de E / S para acceder a los datos del disco, que generalmente es el cuello de botella.
En cuanto a su problema particular, si está escuchando mucho ruido de "búsqueda de disco duro", me parece que su sistema está intercambiando datos de la memoria al disco, y viceversa. Si ha elegido utilizar eCryptfs, Ubuntu encriptará automáticamente su espacio de intercambio (que es necesario para proteger sus datos encriptados). Sin embargo, el intercambio encriptado también es muy costoso.
Personalmente, sobrecargo mis sistemas con mucha RAM (8 GB en la mayoría de mis sistemas) y deshabilito el intercambio por completo.
fuente
Estoy programando con python en mi directorio de inicio, y tengo un entorno virtual de Python para paquetes de proyectos.
Para mis programas, los tiempos de inicio son considerablemente más lentos en eCryptfs ya que Python emite muchas llamadas al sistema stat () cuando localiza archivos de módulos; Debido a que muchas de estas llamadas estadísticas resultan en "archivo no encontrado", y tales resultados nunca se almacenan en la memoria caché, pero aún así pagamos una penalización por los ecryptfs, las cosas son constantemente lentas.
Actualizar
Terminé eliminando ecryptfs de mi directorio de inicio moviendo el punto de montaje ecryptfs a ~ / private, copiando la mayoría de los archivos de ~ / private a mi carpeta de inicio no cifrada. Ahora las cosas vuelven a ser rápidas. Tal vez la penalización de rendimiento sería menor para alguna otra CPU, tengo un Asus 1215N con Atom.
fuente
No he hecho ninguna medición de núcleo duro, así que tome lo siguiente con un grano de sal, pero he notado un rendimiento extremadamente pobre con ecryptfs en los siguientes escenarios en comparación con un LV dm-crypt'd (montado como / home / username):
du en una carpeta con muchos archivos. Lleva varios minutos, mientras que solo unos segundos usa dm-crypt de toda la partición; este es, con mucho, el peor de los casos
abrir una carpeta con muchos elementos en mutt lleva varios segundos (alrededor de 20 en una carpeta con 10000 elementos) mientras que es casi instantáneo con dm-crypt
las operaciones de git son más lentas (para algunos, no mucho) en comparación con dm-crypt
aplicaciones como firefox tardan notablemente más en iniciarse pero todavía estamos en el rango de segundos
¡Me acabo de mudar a dm-crypt (con pam_mount) y no podría estar más feliz!
fuente
Las llamadas como truncate () y ftruncate () que aumentan el tamaño del archivo son más lentas en ecryptfs porque tiene que llenarse con ceros encriptados, a diferencia de los sistemas de archivos normales que solo crean agujeros en el archivo.
fuente