История изменений
Исправление slamd64, (текущая версия) :
Очевидно, сначала декриптуем блочные устройства, а затем собираем полученные виртуальные блочные устройства из /dev/mapper/... в единый LVM том.
Минусы этого дела фееричны: каждое блочное устройство будет криптоваться собственным ключом и будет деградация производительности (при том, что сам по себе LUKS - жестокая деградация производительности!) дисковой подсистемы.
Сделай «sudo cryptsetup benchmark» и посмотри. Вот LVM твой будет работать раза в 1.5-2 медленнее, чем бенч покажет.
IMHO, более правильное решение: объединить НЕКРИПТОВАННЫЕ винты в софтверный MD RAID, а уже поверх этого рейда сделать LUKS. Тогда данные будут криптоваться одним ключом один раз, а только потом отписываться на диски. У себя на хранилочке так и сделал. Реальные последовательные запись и чтение на такой криптованный рейд получились примерно на 1-2% меньше, чем бенч показывал (он только расчет показывает, без реальных записи-чтения).
Исправление slamd64, :
Очевидно, сначала декриптуем блочные устройства, а затем собираем полученные виртуальные блочные устройства из /dev/mapper/... в единый LVM том.
Минусы этого дела фееричны: каждое блочное устройство будет криптоваться собственным ключом и будет деградация производительности (при том, что сам по себе LUKS - жестокая деградация производительности!) дисковой подсистемы.
Сделай «sudo cryptsetup benchmark» и посмотри. Вот LVM твой будет работать раза в 1.5-2 медленнее, чем бенч покажет.
IMHO, более правильное решение: объединить НЕКРИПТОВАННЫЕ винты в софтверный MD RAID, а уже поверх этого рейда сделать LUKS. Тогда данные будут криптоваться одним ключом один раз, а только потом отписываться на диски. У себя на хранилочке так и сделал. Реальные последовательные запись и чтение на такой криптованный рейд получились примерно на 1-2% меньше, чем бенч показывал (он только расчет показывает, без реальной записи-чтения).
Исходная версия slamd64, :
Очевидно, сначала декриптуем блочные устройства, а затем собираем полученные виртуальные блочные устройства из /dev/mapper/... в единый LVM том.
Минусы этого дела фееричны: каждое блочное устройство будет криптоваться собственным ключом и будет деградация производительности (при том, что сам по себе LUKS - жестокая деградация производительности!) дисковой подсистемы.
Сделай «sudo cryptsetup benchmark» и посмотри. Вот LVM твой будет работать раза в 1.5-2 медленнее, чем бенч покажет.
IMHO, более правильное решение: объединить НЕКРИПТОВАННЫЕ винты в софтверный MD RAID, а уже поверх этого рейда сделать LUKS. Тогда данные будут криптоваться одним ключом один раз, а только потом отписываться на диск. У себя на хранилочке так и сделал. Реальные последовательные запись и чтение на такой криптованный рейд получились примерно на 1-2% меньше, чем бенч показывал (он только расчет показывает, без реальной записи-чтения).