LVM volume group из двух LUKS томов

Как бы это дело провернуть?

используй вики арча. https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration https://wiki.archlinux.org/index.php/Dm-crypt

Советуют /etc/crypttab, но используется ли он в Gentoo? Информации по этому поводу не нашел.

Это показалось мне абсурдным, но действительно, упоминания crypttab на вики gentoo нет! (Почти. Есть статья Sakaki's_EFI_Install_Guide но из названия не слишком понятно, следует ли её пользоваться в качестве официальной документации gentoo)

sudo cast Pinkbyte

Подскажи ка, используется ли crypttab в gentoo?

Советуют /etc/crypttab, но используется ли он в Gentoo?

Не в курсе насчёт гентувелосипедов, но если systemd, то точно да.

У меня openrc, надо в /etc/conf.d/dm-crypt писать

/etc/conf.d/dm-crypt писать

В этом случае получаю ошибку при загрузке, т.к dm-crypt стартует позже и LVM не видит второй диск.

Очевидно, сначала декриптуем блочные устройства, а затем собираем полученные виртуальные блочные устройства из /dev/mapper/... в единый LVM том.

Минусы этого дела фееричны: каждое блочное устройство будет криптоваться собственным ключом и будет деградация производительности (при том, что сам по себе LUKS - жестокая деградация производительности!) дисковой подсистемы.

Сделай «sudo cryptsetup benchmark» и посмотри. Вот LVM твой будет работать раза в 1.5-2 медленнее, чем бенч покажет.

IMHO, более правильное решение: объединить НЕКРИПТОВАННЫЕ винты в софтверный MD RAID, а уже поверх этого рейда сделать LUKS. Тогда данные будут криптоваться одним ключом один раз, а только потом отписываться на диски. У себя на хранилочке так и сделал. Реальные последовательные запись и чтение на такой криптованный рейд получились примерно на 1-2% меньше, чем бенч показывал (он только расчет показывает, без реальных записи-чтения).

IMHO, более правильное решение: объединить НЕКРИПТОВАННЫЕ винты в софтверный MD RAID

Который JBOD?

Если нет аппаратного RAID-контроллера :), то mdadm

Спасибо за помощь)

только хотел прокомментировать - ты все грохнул.

initramfs можно вшить прямо в ядро

каким образом, где посмотреть, почитать?

каким образом, где посмотреть, почитать?

При настройке ядра, в General есть соответствующая опция (Initramfs source file(s)). Нужен чистый cpio без сжатия. Необходимые параметры нужно прописать в built-in kernel command line.

это не оно? https://wiki.gentoo.org/wiki/EFI_stub_kernel

Оно. Все описано в подробностях)

1.

каждое блочное устройство будет криптоваться собственным ключом и будет деградация производительности

2.

винты в софтверный MD RAID, а уже поверх этого рейда сделать LUKS. Тогда данные будут криптоваться одним ключом один раз, а только потом отписываться на диски

Не очень понятно, как выглядит то, о чем ты говоришь.

Вот есть HDD1 и HDD2. Откуда возьмутся преимущества п.2 перед п.1 ? (Я не вижу, где в п.1 будет шифрование данных больше одно раза, вот это мне не понятно)

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

Два LUKS раздела объединяются в LVM volume group. Каждый из них зашифрован со своим ключем.

Как работает LVM? LVM - не блочное устройство. Это именно хранилище.

Предположим в основе LVM два диска. Пишем два файла.

1-й файл запишется на 1-й диск 1-м ключем.

2-й файл запишется на 2-й диск 2-м ключом.

Поскольку диски независимые, файлы независимые, то писаться это всё будет параллельно. А, значит, вычислительные мощности процессора по шифрованию поделятся между двумя этими потоками. Да там ещё накладные расходы на две независимые файловые системы и прочее в том же духе.

При RAID-массиве LUKS-контейнер будет ОДИН: поверх самого массива. На аппаратный/софтверный RAID-контроллер уже приходит закриптованная информация и распределяется по дискам.

спасибо за наводку.

Предположим в основе LVM два диска. Пишем два файла.

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