Размер Stripe-unit в RAID0

Когда читаешь/записываешь больше 1 stripe-unit процесс может быть распараллелен (читай ускорен).

Не знаю как сейчас, но раньше максимальный размер блока данных при запросе ограничен (обычно 64-320к) т.ч. больше 256к ставить небыло смысла.

IMHO На размер файлов при выборе размера stripe-unit ориентироваться не стоит. Выбирать нужно из характера операций ввода/вывода: если обмен идет небольшими блоками, то и размер stripe есть смысл уменьшить, а если это читается большими блоками, то увеличить. В принципе, выбор остается небольшой - 32/64/128к.

Если файлы большие, то в районе 1Мбайт и больше вполне подходит. Если мелкие, то 32-64-128-256 в зависимости от.

На деле влияет достаточно слабо.

Классический вариант — 64k.

LUKS

Оставляй 512, если нет ускорения AES.

Ускорение AES есть в процессоре (AMD FX-6300). А какая может быть связь?

А какая может быть связь?

Шифрование нивелирует разницу в производительности между разными размерами chunk.

Ускорение AES есть в процессоре (AMD FX-6300).

Нормально работает?

Поддержка вроде бы везде заявлена. Вроде работает: не могу придумать тест, чтобы точно узнать.

Вот что сходу нагуглилось:

http://www.tomshardware.com/reviews/RAID-SCALING-CHARTS,1735-6.html

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

Вроде работает: не могу придумать тест, чтобы точно узнать.

в dmesg ничего нет?

Да наверно не будет особой разницы. Я почему-то думал про RAID5/6, когда писал, а это далеко не то же самое %)

[root@storage ~]# lsmod |grep aes
aesni_intel            50585  48 
cryptd                 10420  17 aesni_intel
aes_x86_64              7880  1 aesni_intel
aes_generic            27575  2 aesni_intel,aes_x86_64
[root@storage ~]#

то есть все ок.

AMD FX-6300

aesni_intel

Intel

Ок :)

Правда, не похоже что там чудовищная разница в перформансе: http://www.phoronix.com/scan.php?page=article&item=intel_aesni_dmcrypt&am...

Intel

Ну так набор инструкций же.

Ну, по бенчмарку того же Truecrypt под оффтопиком с AES-NI скорость на 4-ядерном Core i5 2.5Гбайт\сек, без - где-то 300Мбайт\сек. Разница очень даже на лицо :)

Под линуксом можно померять так (Гонял на Core i5-3570T):

# echo "0 268435456 zero" | dmsetup create zerodisk
# cryptsetup create --hash sha1 --cipher aes zerocrypt /dev/mapper/zerodisk
Enter passphrase: (любую)
# dd if=/dev/mapper/zerocrypt of=/dev/null bs=1M count=16384
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB) copied, 34.9443 s, 492 MB/s
# dd of=/dev/mapper/zerocrypt if=/dev/zero bs=1M count=16384
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB) copied, 18.3945 s, 934 MB/s

Ну и без модуля aesni проверить то же самое.

С aesni:

┌──[23:20:21]─[root@ux32vd]─[~]
└──# dd if=/dev/mapper/zerocrypt of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 3.05899 s, 343 MB/s
┌──[23:20:36]─[root@ux32vd]─[~]
└──# dd of=/dev/mapper/zerocrypt if=/dev/zero bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 1.65762 s, 633 MB/s

Без:

┌─[1]─[23:17:45]─[root@ux32vd]─[~]
└──# dd of=/dev/mapper/zerocrypt if=/dev/zero bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.93617 s, 177 MB/s
┌──[23:17:56]─[root@ux32vd]─[~]
└──# dd of=/dev/null if=/dev/mapper/zerocrypt bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.96721 s, 176 MB/s

Проц i7-3517u. Щас сравню с тем что намеряли в похорониксе....

А, я понял, у них всё в ssd упёрлось. Ну чтож, по крайней мере теперь понятно что это имет наибольший смысл с быстрыми стораджами/загруженным процом.

Ну, если aes-ni есть, то грех его не юзать, в любом случае :)

бесспорно :)