Как ecryptfs влияет на производительность жесткого диска?

Мой дом зашифрован с помощью ecryptfs. Приводит ли ecryptfs к фрагментации?

У меня такое ощущение, что чтение файлов, отображение папок и вход в систему становились все медленнее и медленнее (хотя вначале это не было заметно медленным). Жесткий диск издает много шума при поиске, даже если я открываю только текстовый файл. В /home/.ecryptfs я вижу много больших архивов (которые, вероятно, содержат зашифрованные файлы), поэтому мне интересно, выигрывает ли здесь что-нибудь в результате онлайн-дефрагментации файловой системы Linux.

Какие варианты у меня есть, чтобы увеличить производительность? Должен ли я решить, лучше ли мне обходиться без шифрования?

Источник

4 ответа

Phoronix провел набор тестов и несколько статей о производительности eCryptfs при шифровании домашних каталогов:

Мой вывод из этих статей заключается в том, что шифрование (как и ожидалось) в соответствии с тестами в определенной степени влияет на производительность чтения и записи. На небольших процессорах (процессорах Atom) и на быстрых жестких дисках (SSD) это, пожалуй, более заметно. Тем не менее, используя eCryptfs, вы платите только это снижение производительности при чтении / записи данных в свой домашний каталог (а не в остальную часть системы, как это было бы при использовании полнодискового шифрования). Более того, при использовании более быстрых процессоров время, затрачиваемое на шифрование / дешифрование, часто соответствует ожиданию ввода-вывода при доступе к данным с диска, что обычно является узким местом.

Что касается вашей конкретной проблемы, если вы слышите много шума "поиска жесткого диска", мне кажется, что ваша система обменивается данными из памяти на диск и обратно. Если вы решили использовать eCryptfs, то Ubuntu автоматически зашифрует ваше пространство подкачки (что необходимо для защиты ваших зашифрованных данных). Однако зашифрованный своп тоже очень дорогой.

Лично я перегружаю свои системы большим количеством оперативной памяти (8 ГБ на большинстве моих систем) и полностью отключаю обмен.

Источник

Я программирую на python в своем домашнем каталоге, и у меня есть виртуальная среда Python для пакетов проектов.

Для моих программ время запуска на eCryptfs значительно медленнее, поскольку Python выполняет много системных вызовов stat() при поиске файлов модулей; поскольку многие из этих вызовов статистики приводят к "файлу не найден", и такие результаты никогда не кэшируются, но мы все равно платим штраф за ecryptfs, ситуация неизменно вялая.

Обновить

В итоге я удалил ecryptfs из моего домашнего каталога, переместив точку монтирования ecryptfs в ~/private, скопировав большинство файлов из ~ / private в мою незашифрованную домашнюю папку. Теперь все снова быстро. Может быть, снижение производительности будет меньше для какого-либо другого процессора, у меня Asus 1215N с Atom.

Источник

Я не делал каких-либо жестких измерений ядра, поэтому возьмите следующее с большой долей соли, но я заметил чрезвычайно низкую производительность с ecryptfs в следующих сценариях по сравнению с LV dm-crypt'd (смонтированным как /home/username):

  • на папке с большим количеством файлов. Это займет несколько минут, а всего несколько секунд, используя dm-crypt всего раздела - это, безусловно, худший случай

  • Открытие папки с большим количеством элементов в Mutt занимает несколько секунд (около 20 в папке с 10000 элементов), в то время как это почти мгновенно с помощью dm-crypt

  • Git-операции медленнее (по некоторым, не очень) по сравнению с DM-Crypt

  • такие приложения, как firefox, запускаются заметно дольше, но мы все еще находимся в диапазоне секунд

Я только что переехал в dm-crypt (с pam_mount) и не мог быть счастливее!

Источник

Такие вызовы, как truncate() и ftruncate(), которые увеличивают размер файла, медленнее работают с ecryptfs, потому что он должен заполняться зашифрованными нулями, в отличие от обычных файловых систем, которые просто создают дыры в файле.

Источник
Другие вопросы по тегам