По правде говоря, сравнения AES vs Blowfish по сути нет. Blowfish был выбран исключительно для разнообразия эксперимента. Обычно в тестах подобного рода принято указывать кучу сопряженных параметров, я позволю себе практически все их опустить по одной простой причине — на качестве эксперимента они не отразятся, т.к. сравнение носит относительный характер, а не абсолютный. Отмечу лишь следущее:
- для тестирования выбран обычный находившийся под рукой SATA диск — Seagate ST3250620NS. Процедуру инициализации устройств можно подсмотреть на странице ресурса OpenNet.RU;
- в качестве базы выбрана файловая система ext2;
- прямое влияние кэша файловой системы отсутствует, т.к. в обоих случаях: dd и bonnie++,- использовались файлы значительно большего размера, чем оперативная память;
- вызов команды dd на запись dd if=/dev/zero of=<filename> bs=256k count=20000. Легко прикинуть, что результирующий файл составил 5000 MB. Флаг oflag=direct не использовался лишь по одной причине — на первых экспериментах я откровенно забыл его включить, а возвращаться к ним просто не хотелось;
- вызов команды dd на чтение dd if=<filename> of=/dev/null bs=256k;
- вызов команды bonnie++ -f -b -u 0
Результаты представлены на двух диаграммах. Полученные результаты представлены в формате CSV.
Итог достаточно радужный. Нетрудно заметить, что dm-crypt с LUKS EXTENSION продемонстрировала хорошие показатели, максимально приблизившись к показателям партиции без шифрования для случая записи и отстала от последней для случая чтения всего лишь на четверть (25%).
А в тестах с шифрованием загрузка процессора всегда была под 100%?
Большую часть времени занимал iowait, raw данные bonnie++ доступны по ссылке — http://blog.unixstyle.ru/uploads/data/dd.csv. Получить human-readable формат можно скормив .csv-файл команде bon_csv2html.
Дельная статья, сам последнии пару недель ходил с подобной мыслью о тестировании, а тут как раз вы.
А хранить на шифрованом програмным способом разделе файлы БД не пробовали? Интересно насколько критично по производительности будет.
Нет, задача заключалась в шифровании раздела для отдачи файлов большого раздела. ИМХО, шифрование может загубить на корню производительность БД.
На днях попробую все же потестить и отпишусь, очень критично для одной задачи хранить файлы postgres в шифрованом виде, ищу куда копать, может аппаратно шифровать hdd?
>> На днях попробую все же потестить и отпишусь,
Было бы интересно посмотреть на результаты.
>> может аппаратно шифровать hdd?
В любом случае аппаратные решения дадут больший задел по производительности.