Плохая производительность записи на ecryptfs

Я провел небольшой сравнительный анализ с ecryptfs и dm-crypt и получил несколько интересных результатов. Все следующее было сделано с файловой системой Btrfs, использующей ddдля копирования файла ~ 700 МБ на / с виртуального диска с conv=fdatasyncвозможностью принудительной синхронизации данных. Кэши дисков очищались перед каждым тестом.

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

Теперь я понимаю, что шифрование медленнее, чем в сырой файловой системе, однако я не ожидал значительного снижения производительности записи с помощью ecryptfs. Тот факт, что я вынужден синхронизировать данные, делает этот тест нереальным? Или есть какие-то опции, которые я могу передать ecryptfs, чтобы записи работали быстрее?

Я использовал шифрование имени файла на ecryptfs, но кроме этого все было установлено по умолчанию.

— Xenopathic
источник

Сравнительный анализ может быть сложным, и иногда тест достигает неожиданных пределов, особенно при принудительном выполнении синхронных записей. Я не знаком с внутренней работой ecryptfs, но вы должны обязательно исключить любые проблемы с усилением записи. Какой размер блока использует ecryptfs, и что вы указали для dd? Если ecryptfs зашифровывает 16 Кбайт за раз, и вы пишете блоки меньшего размера, каждая синхронизация заставит чтение извлечь блок, затем изменить данные, затем зашифровать и, наконец, записать. Это может объяснить показатели производительности, подобные этим.

— Кетил

Man-страница ddabout fdatasyncreads:, physically write output file data before finishingпоэтому физически данные записываются только «один раз» (читается как «не форсировать сброс X блоков или байтов, а только сброс в конце»). Если вы используете ddдля своих тестов, это лучший способ получить наиболее точные результаты. Напротив, если не использовать этот конкретный флаг, вы сделаете ваши результаты нереалистичными: если вы пропустите его, то, вероятно, упустите время для самого шифрования, поскольку ddпросто копируете данные.

Тем не менее, я также думал, что что-то происходит с вашими результатами, но я обнаружил, что эта статья показывает почти то же самое: ecryptfs мучительно медленен. И ваш тест ( копируется один файл ) - лучший сценарий для ecryptfs!

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

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

С другой стороны, dm-crypt может быть намного быстрее, но вам нужно будет отправить весь контейнер (целую файловую систему), чтобы сохранить шифрование как есть. И резервные копии также будут состоять из целого контейнера, и в большинстве случаев они не смогут создавать инкрементные резервные копии.

Я использовал (и до сих пор использую) оба метода (но не те же инструменты) для хранения зашифрованных данных: синхронизировать файлы на основе файлов (ecryptfs) легче, если использовать такие службы онлайн-хостинга, как dropbox между компьютерами, но это довольно медленно, когда внесение изменений и вызвало у меня некоторые проблемы с лежащей в основе файловой системой (предполагается, что она может записывать файлы, а проблемы, связанные с ограничениями в файловой системе, как правило, разрушают все это); Я предпочитаю шифрование на блочных устройствах: я отношусь к ним как к простым разделам, поэтому ограничения и проблемы не так плохо нарушаются. Единственный недостаток - копирование контейнера, которое может занять больше времени.

— NuTTyX
источник