Как стать автором
Обновить

Комментарии 24

Truecrypt и eCryptfs почти одинаково копируют по вашим данным (199.719 и 199.624). Откуда взялась разница в 49%?
199 секунд — это результат одного-единственного теста dd блоками 4килобайта размера файла 500мб. Проценты считаются по результатам 1600+ тестов, среди которых разный размер файла и блока.
Хотелось бы сравнения с encfs, если это возможно.
Возможно, постараюсь сделать.
Благодарю заранее.
Готово.
Спасибо. Интересный результат.
Нет я понимаю, что значение по умолчанию это интересно. Но смысл сравнивать производительность, когда в одном случае размер хеша 160бит, в другом 256?
В статье я уже писал об этом — я, как обычный пользователь в криптографии не соображаю дальше выбора алгоритма шифрования, поэтому везде применяются параметры алгоритмов по-умолчанию.
dd — это последовательная запись, хотелось бы увидеть замеры при random access — как это бывает в реальной жизни шифрованной ФС.
man iozone говорит, что утилита делает следующие тесты: Read, write, re-read, re-write, read backwards, read strided, fread, fwrite, random read/write, pread/pwrite variants. Сравнение в процентах велось по всем этим тестам. Отчеты iozone я, естественно, не выкладывал, т.к. они очень большие.
То что iozone умеет это делать это понятно. У вас не указано с какими именно ключами вы её запускали.
Вот отчёты как раз можно было и загнать в MS Excel/LibreOffice Spreadsheet и построить графики — так как на первой картинке.
У меня указано. iozone -a Used to select full automatic mode. Produces output that covers all tested file operations for record sizes of 4k to 16M for file sizes of 64k to 512M. Графики можно построить, но у меня не было такой цели. Целью было посчитать среднее падение производительности в процентах.
1. В новых процессорах имеется аппаратная поддержка AES. насколько мне известно, в Intel Celeron поддержки AES нет. Хотелось бы увидеть результаты тестов на процессоре с аппаратной поддержкой AES.

2. Часто используется LVM совместно с шифрованием, например, LUKS. Говорят, что оверхед LVM в LUKS больше суммарного оверхеда LUKS и LVM, так как LVM читает и пишет за раз довольно большой блок информации (4 Мб). Особенно заметно при размещении swap в LVM в LUKS, так как для чтения или записи 4 кб (страница свопа) будет перешифровано 4 Мб. Говорят, что своп выгоднее выносить наружу и шифровать одноразовым случайным ключом, но такой своп нельзя использовать для hibernate. Хотелось бы разобраться, насколько это соответствует истине. Проведите, пожалуйста, тесты на системах LVM-in-LUKS и LUKS-in-LVM.
1. В новых процессорах имеется аппаратная поддержка AES. насколько мне известно, в Intel Celeron поддержки AES нет. Хотелось бы увидеть результаты тестов на процессоре с аппаратной поддержкой AES.

Согласен. Только при использовании проверять, загружен ли модуль aesni_intel. В squeeze у меня было вместо него подключался другой модуль, не использовавший аппаратное шифрование.
И вообще достаточно интересное тестирование шифрования AES приведено здесь.
1. У меня нет ни одниго из поддерживаемых процессоров, поэтому данный тест я провести не смогу.
2. Принято, сделаю.
Опубликую результаты сюда, а не в топик
Сперва я сделал полное тестирование (iozone -a), результаты:
1) LVM-in-LUKS
Количество проведенных серий тестов: 6
Средняя разница в производительности между одинаковыми сериями тестов: 0,7%
dd: 524288000 bytes (524 MB) copied, 214.065 s, 2.4 MB/s
Падение производительности по сравнению с нешифрованной ФС: 8%
2) LUKS-in-LVM
Количество проведенных серий тестов: 6
Средняя разница в производительности между одинаковыми сериями тестов: 3%
dd: 524288000 bytes (524 MB) copied, 215.45 s, 2.4 MB/s
Падение производительности по сравнению с нешифрованной ФС: 8%

Хотя тест dd и немного медленнее, но, в среднем по всем тестам, производительность такая же, как и у чистого LUKS. Скорость в обоих случаях одна. Так, как вы писали о маленьких файлах, то я провёл дополнительный тест только для них, используя ключи iozone -a -g 4m (провести тест только для файлов, меньших 4 мб), результаты:
1) LVM-in-LUKS
падение производительности: 0,5%
2) LUKS-in-LVM
падение производительности: 2%
Для маленьких файлов разница тоже небольшая, возможно даже, объяснимая погрешностью измерения.
Шансы призвать больше, если написать amarao.
Так точно, готово! :)
Несколько фундаментальных замечаний по тесту.

eCyptfs шифрует на уровне файловой системы, а все остальные — на уровне блочного устройства. Это означает:

для шифрующих на уровне блочного устройства

[benchmark] => [filesystem] => [cache] => [crypto] => [underlaying block device]

Для ecryptfs
[benchmark] => [crypto] => [filesystem] => [cache] => [underlaying block device]


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

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

Использование iozone или fio в данном случае неправильно, потому что разные тесты имеют разное отношение к жизни, и с какими весами их учитывать — вопрос открытый.

Я бы предложил запуск типовых задач (например, запуск гимпа с командой «выход», «время выполнения debootstrap c локального репозитория») с прогретым кешем и без и т.д.

Как пользователь ecryptfs я могу сказать, что она «тормозит» на файловых операциях больше (т.к. вынуждена синхронно шифровать метаданные минуя кеш), но вполне прилично себя чувствует на операциях внутри файла (то есть в потоковых операциях).
Спасибо!
Спасибо за тесты и за обновление для encfs. Пользуюсь encfs в paranoia режиме. Подозревал, что она проиграет в тестах. Попробую eCryptfs, раз оно побыстрее. Но хочу сказать, производительности encfs хватает даже на просмотр фильмов. Переход к произвольной позиции в фильме занимает меньше секунды. Для мелких файлов вроде исходников эффект совсем незаметен. Одноядерный процессор Atom, нетбук. К серьёзным недостаткам могу отнести ускоренную посадку батареи, примерно в полтора раза.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории