Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Хорошо бы графики
Truecrypt и eCryptfs почти одинаково копируют по вашим данным (199.719 и 199.624). Откуда взялась разница в 49%?
Хотелось бы сравнения с 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 и построить графики — так как на первой картинке.
Вот отчёты как раз можно было и загнать в 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.
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. Принято, сделаю.
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%
Для маленьких файлов разница тоже небольшая, возможно даже, объяснимая погрешностью измерения.
Сперва я сделал полное тестирование (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
Традиционно призываю в топик amarao
Шансы призвать больше, если написать amarao.
Несколько фундаментальных замечаний по тесту.
eCyptfs шифрует на уровне файловой системы, а все остальные — на уровне блочного устройства. Это означает:
для шифрующих на уровне блочного устройства
Для ecryptfs
Поскольку все тесты проводились с включенными кешами, то большая часть файловых тестов для блочных устройств вообще не затрагивала шифрования в синхронном режиме. Данные или в кеше, или в кеш пишутся. Для ecryptfs все данные синхронно проходили через шифрование, а потом уже оказывались в кеше под файловой системой.
В общем случае я не могу назвать неправильным учитывание взаимодействия кеша и шифрования (т.к. пользователь жить будет с кешами), но их следует явно учитывать в тестах, то есть, например, явно сбрасывать перед каждым тестом или одинаково прогревать.
Использование iozone или fio в данном случае неправильно, потому что разные тесты имеют разное отношение к жизни, и с какими весами их учитывать — вопрос открытый.
Я бы предложил запуск типовых задач (например, запуск гимпа с командой «выход», «время выполнения debootstrap c локального репозитория») с прогретым кешем и без и т.д.
Как пользователь ecryptfs я могу сказать, что она «тормозит» на файловых операциях больше (т.к. вынуждена синхронно шифровать метаданные минуя кеш), но вполне прилично себя чувствует на операциях внутри файла (то есть в потоковых операциях).
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, нетбук. К серьёзным недостаткам могу отнести ускоренную посадку батареи, примерно в полтора раза.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение производительности различных систем шифрования под linux