Назад | Перейти на главную страницу

Сравнение производительности SSD + LUKS?

Наши ноутбуки и портативные накопители должны быть зашифрованы LUKS. LUKS, похоже, не вызывает больших потерь производительности на обычных жестких дисках ноутбука (7200 об / мин) для нас. Это все еще правда, учитывая сумасшедшие скорости передачи данных, которые вы получаете с твердотельными накопителями?

Я немного поискал, но я не нашел никаких реальных сравнений между LUKS и не-LUKS на SSD.

В настоящее время я наблюдаю производительность 150 МБ / с с моим SSD и LUKS. Это потеря 50%, поскольку без LUKS мой SSD будет иметь скорость чтения 300 МБ / с.

Я использую Fedora 17 с ядром Linux 3.4.

Да, использование ЦП для шифрования будет расти, однако, если машина не связана иным образом с ЦП, я бы ожидал, что ввод-вывод по-прежнему будет узким местом, поскольку большинство современных компьютеров должны иметь возможность превышать 250 МБ / с AES (это SATA-3g пропускная способность)

Тесты AES-NI с SSD находятся по ссылке ниже, проверьте это: http://dentarg.it64.com/content/luks-and-intel-aes-ni-performance-part-2

А как насчет процессоров, у которых нет аппаратного ускорения при шифровании ... или без использования AES ... и т. Д.

Скорость может снизиться до 15 МБ / с (каскадные алгоритмы, такие как Serpenter и Twofish) ... в то время как два SSD в Linux Software Raid 0 могут получить более 950 МБ / с.

Потеря скорости «огромна», очень «огромна» .... в моем тесте от 993 МБ / с до 13,8 МБ / с.

Это ноутбук, в который я поместил два Samsumng SSD 740 EVO, один в нормальный слот 2.5, другой на тележку, где был DVD ... RAM 8GIB и довольно старый процессор без AES и только 3 ГГц с Dual core.

Я согласен с Anonymous, я провел тест на 64-гигабайтной RAM Ryzen 7 2700x (16 потоков на 8 ядрах), и при рендеринге (максимальное использование ЦП) количество операций ввода-вывода на SSD LUK сильно падает.

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

Идентичная ситуация для быстрого перекодирования MPEG2 (DVD VOB) в MP4, ЦП перегружен, поэтому для LUKS нет свободного ЦП.

Просто совет: если мы говорим о быстром NVMe (запись 3000 МБ / с), раскрывающийся список будет таким же, вы получите несколько мегабайт записи в секунду при интенсивной загрузке процессора.

И это тестировалось на Ryzen 7 2700X с тактовой частотой 4,35 ГГц (8 ядер / 16 потоков) с 64 ГБ оперативной памяти 3200 МГц.

Еще один совет: AES сломан и имеет лазейки, хуже всего, если это аппаратное обеспечение, встроенное в процессоры Intel AES (или также худший внутренний AES жесткого диска), на всякий случай не используйте AES для LUKS, а также жесткие диски ( HDD и / или SSD) со встроенным аппаратным шифрованием, если вы не используете на них ATA-пароли, любой злоумышленник может запустить быструю команду (менее 0,1 с) на него и активировать смену ATA-пароля (с пустого до непустого) и при следующем отключении питания ваши данные будут похищены, вы не сможете получить доступ к этому диску без этого пароля ATA.

Программное шифрование против скорости, аппаратное шифрование даже небезопасно.