LINUX.ORG.RU
Форум — General  

Производительность LUKS, Hardware RAID, no AES-NI, multithreaded

 , ,


0

3

Есть домашняя машина на старом железе.

LSI контроллер и RAID0 массив из 6 дисков.

Чтение диска выдает хорошую скорость линейного чтения. Результат из DD:

5368709120 bytes (5.4 GB, 5.0 GiB) copied, 7.96162 s, 674 MB/s

Но чтение с раздела LUKS выдает уже в 2 раза меньше:

5368709120 bytes (5.4 GB, 5.0 GiB) copied, 19.8654 s, 270 MB/s

Скорее всего ограничение в скорости дешифрования. Проц старый Phenom II X4 на частоте 3.8 все 4 ядра.

htop показывает, что во время чтения используется либо 1 ядро на 100%, либо 2 ядра приблизительно каждое на 70%.

Cryptsetup benchmark показывает такую картинку, притом грузится только одно ядро:

#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       233.3 MiB/s       255.0 MiB/s
    serpent-cbc        128b        98.4 MiB/s       252.6 MiB/s
    twofish-cbc        128b       220.4 MiB/s       264.4 MiB/s
        aes-cbc        256b       184.7 MiB/s       197.2 MiB/s
    serpent-cbc        256b        98.4 MiB/s       252.3 MiB/s
    twofish-cbc        256b       220.1 MiB/s       264.0 MiB/s
        aes-xts        256b       253.2 MiB/s       255.5 MiB/s
    serpent-xts        256b       231.4 MiB/s       234.8 MiB/s
    twofish-xts        256b       248.7 MiB/s       246.7 MiB/s
        aes-xts        512b       195.2 MiB/s       197.2 MiB/s
    serpent-xts        512b       231.5 MiB/s       235.2 MiB/s
    twofish-xts        512b       248.8 MiB/s       246.4 MiB/s

Ось Fedora 29 (4.19.8-300.fc29.x86_64).

Может кто сталкивался?

Возможно ли утилизировать все ядра при шифровании, дешифровании?

← Загрузка и работа с usb, восстановление после сбоя
zabbix мониторинг кодов 200 502 503 nginx →

Не уверен, что что-то подскажу, но для начала было бы неплохо узнать используемый алгоритм.

И потом нужно ведь понимать, что голый Raid0 на 6 дисков это шесть отдельных очередей ввода-вывода.

А LUKS поверх - это одна очередь, со всеми вытекающими. Даже безотносительно способности параллелить крипту в dm-crypt.

Даже если dm-crypt начнёт честно грузить все ваши ядра, то цифры всё равно не сойдутся.

Bebop ★★
()
Ответ на: комментарий от Bebop

cryptsetup выдал вот это:

  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sdb1
  sector size:  512
  offset:  4096 sectors
  size:    11707015168 sectors
  mode:    read/write
  flags:   discards

во время установки никаких опций не предлагалось

возможно 512 bit ключ перебор, хватило бы AES-128 и 256 bit ключа

но не уверен помогло бы это или нет, возможно это хорошая идея перекриптовать раздел, надо почитать как

maxlinux
() автор топика
Ответ на: комментарий от maxlinux

aes-xts-plain64

Это, действительно, значение по умолчаию. Но из вопроса не очевидно.

Когда-то были особенности в многопоточной обработке, к примеру, CBC в зависимости от чтения/записи.

Про XTS ничего не скажу. Я, если честно, думал, что проблемы многопоточной обработки в dm-crypt давно решены.

Если накопаете чего-то актуального, то я с удовольствием тоже бы почитал.

Bebop ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Загрузка и работа с usb, восстановление после сбоя
General
zabbix мониторинг кодов 200 502 503 nginx →