LUKS + LVM + swap = «замерзание» UI при использовании swap

Проблема в том, что данные в LVM организованы экстентами, а не блоками. Размер по-умолчанию, вроде бы 4 Мб (если ты не изменил). Теперь представляем ситуацию, когда на случайном доступе, что типично для свопа, система начитает доставать оттуда данные по 4 Мб. Да еще и памяти для дискового буфера нет. Понятна проблема?

Рекомендация: переразбить систему так, чтобы swap, /, /var, /usr, /tmp не были зашифрованы (/tmp можно запихать в tmpfs), а шифровался только /home (или что Вы там бережете) и размер экстента в LVM был _не больше_ 4Мб.

Идея ясна. Спасибо.

Сейчас делаю такой временный вариант (костыль, конечно, но зато переразбивка не нужна):
1) swap вне LVM шифруется случайным ключом
2) ему даётся бОльший приоритет (опция монтирования)
В итоге swap, который внутри LVM, будет фактически использоваться только для hibernate. A swap на физическом разделе будет использоваться фактически по назначению. При этом всём при выходе из hibernate нужен будет только один пароль ;)

Идея неплохая, но мне кажется, что сложно /если вообще возможно/ будет заставить эту систему работать. Уж проще смириться с нешифрованным свопом — вряд ли те, кто сможет украсть копм будут возиться с анализом свопа.

Только что проверил. Своппинг при исчерпании ОЗУ работает как задумано, т.е. вначале заполняется своп с реального раздела, при этом «замерзания» UI не наблюдается, только подтормаживание.
hibernate также работает нормально.
В общем, как временное решение сойдёт, а когда будет время, конечно, сделаю переразметку диска.

Сейчас всё выглядит так:

crypttab:

sda6_crypt UUID=xxxxxxxxxxxxxxxx none luks
crealswap /dev/sda8 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

из fstab:

# /boot was on /dev/sda5 during installation
UUID=xxxxxxxxxxxxxxxx      /boot           ext3    defaults          0       2
/dev/mapper/debian-debroot /               ext4    errors=remount-ro 0       1
/dev/mapper/debian-debswap none            swap    sw                0       0
/dev/mapper/crealswap      none            swap    sw,pri=32000      0       0

Я вот чего не пойму: а почему при гибернации система выбирает своп-раздел на LVM, на не физическом разделе? Или ты выполняешь swapoff в pm-скриптах?

Точно не уверен, но, думаю, что раздел, откуда система будет пытаться восстановиться, указывается в /etc/initramfs-tools/conf.d/resume
У меня там такое: RESUME=/dev/mapper/cdebswap

По идее, это «вшивается» в initrd.img каждый раз, когда он генерируется.

RESUME=/dev/mapper/cdebswap

кстати, а должно быть /dev/mapper/debian-debswap

хм....

кстати, а должно быть /dev/mapper/debian-debswap

Разобрался. Это потому что корень был «склонирован» с десктопа. Это всё равно нужно было поменять, иначе после очередного обновления ядра hibernate бы перестал работать ;)

Это потому что корень был «склонирован» с десктопа.

То есть система была поставлена средствами debian-installer'а, а потом всё, кроме /boot было «склонировано» с десктопа.
Почему проблема до сих пор не проявилась? Потому что не обновлял ядро ;)

Понятно. Спасибо.