устойчивость шифрованных разделов к сбоям питания.

На последний вопрос ответ -- скорее всего, все будет нормально. Система перед выключением принудительно сбрасывает содержимое кэшей, отмонтирует устройства и только потом отключает питание.

2 года на работе еспользую шифрованные cryptoloop twofish разделы (по 20-40Гб) - никаких сбоев не было. Персонал - не особо технически грамотный, - часто и ресет нажимают, если что не так покажется (по форточной привычке).

Просто cryptoloop / dm-crypt - согласен. Если что-то и побьётся - то просто либо содержимое файлов (никуда не денешься), либо, если файловая система - то ext3 за счёт журнала разберётся. А вот в случае с luks я опасаюсь, что побьётся его заголовок. Тогда при следующем подключении до ext3 дело может не дойти и никакое журналирование будет не при чём.

> Система перед выключением принудительно ... отмонтирует устройства

Это в идеале. Но в действительности:
- что будет, если при таком отмонтировании ответ системе будет "busy"?
- сможет ли система сказать не только umount, но и cryptsetup luksClose для зашифрованного с использованием LUKS диска? Или ограничится umount /dev/mapper/...? Кстати, а что будет, если не сказать cryptsetup luksClose?

> что будет, если при таком отмонтировании ответ системе будет "busy"?

Если я правильно понимаю то такого впринципе быть не может. Ядро же, убивает все процессы сначала посылая им SIGTERM, а оставшимся неадекватам SIGKILL. Так как он тогда может быть busy?

есть такой диск. с двумя зашифроваными разделами, первый на ext3 второй на reiserfs.
как-то добрые люди вырвали усб-шнурок из порта ... но ничего серьезного
не произошло, ничего не пропало/пострадало. один раз на ext3 журнал упал
просто во время копирования больших файлов, но это тоже восстановить можно.
в дебиане, если во время загрузки системы шифрованный диск подключен, спрашивается
пароль и диск автоматом монтируется. отмонтируется тоже без проблем.

> Если я правильно понимаю то такого впринципе быть не может. Ядро же, убивает все процессы сначала посылая им SIGTERM, а оставшимся неадекватам SIGKILL. Так как он тогда может быть busy?

Может. Если процесс вызвал функцию ядра, то он ждет ее завершения. Если функция не завершается(а такое было с CDFS - для монтирования аудио-дисков), то процесс не реагирует даже на SIGKILL

> Ядро же убивает все процессы, сначала посылая им SIGTERM, а оставшимся
> неадекватам SIGKILL. Так как он тогда может быть busy?
Бывают же неубиваемые процессы. Зомби, или как их там (буквой D помечаются в выводе ps, если правильно помню). Ведь один из них вполне может зацапать диск, имхо.

> один раз на ext3 журнал упал
Журнал может падать?! Я думал, он как раз от падучести сделан :-)

> в дебиане... отмонтируется тоже без проблем.
Это обнадёживает :-)
Интересно, что насчёт Слаки?

Ну с зомби как раз очень легко разобраться. Тем более когда процесс зомби он же ничего не делает, а просто тупо не может найти своего родителя :)

Спасибо, буду знать :)

Есть опция отмонтирования -l, так-же можно перемонтировать ro и этого достаточно.

>> один раз на ext3 журнал упал
>Журнал может падать?! Я думал, он как раз от падучести сделан :-) 

или хз как это называется, но при этом ext3 превращается в ext2.

Ничего страшного не будет, разве что вы какойнить CBC не йузаете :)

CBC - в смысле Cipher-block chaining?
Из Вики для dm-crypt: "However, the CBC mode is still the default for compatibility with older volumes." Так как я для начала особо эти опции не крутил, то, похоже, что у меня используется именно этот вариант. Чем это грозит?