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

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

• http://www.phoronix.com/scan.php?page = article & item = ubuntu_910_encryption & amp; num = 1
• http://www.phoronix.com/scan.php?page=article&item=ubuntu_jaunty_encrypt&num=1

Мое изъятие из этих статей заключается в том, что шифрование (как и ожидалось) в соответствии с тестами в определенной степени влияет на производительность чтения и записи. На небольших процессорах (процессорах 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 ):

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

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

• операции с git выполняются медленнее (некоторыми, не так много) по сравнению с dm-crypt

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

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

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