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

Что-то все молчат. Колись :)

dm_crypt -- этож блочное шифрование. поэтому будет всё ровно тоже самое что и без шифрования вовсе, всё только файловой системы зависит которая у тебя на самом последнем уровне.

При недозаписи зотя бы одного байта в блоке неудастся расшифровать весь блок. А блоки там не маленькие(размер не понмю :(). Я дусвю этим всё и объясняется.

В общем, все данные накрылись в обоих случаях.

В первом случае эмулировал запись лога когда через dd на пустом разделе создавал большой файл(больше 3G, sync периодически набирал). После перезагрузки ни осталось ничего, df сообщал отрицательный размер места. После проверки диска вылезли ошибки, файла нет.

Второй тест был таким же тока на разделе штук пять файлов было по 512кб. После их создания набрул sync(не уверен что это гарантирует сброс кэша на всех уровнях абстракции диска), пождал немного и повторил первый тест. Никаких файлов не оказалось. Вроде даже lost+found исчез, но я не помню. df сообщал что раздел пустой, fsck ничего серьёзного не нашёл.

PS была ext4. Повторю эксперименты с ext3, но не думаю что это что-то поменяет.

> При недозаписи зотя бы одного байта в блоке неудастся расшифровать весь блок. А блоки там не маленькие(размер не понмю :(). Я дусвю этим всё и объясняется.

> В общем, все данные накрылись в обоих случаях.

> В первом случае эмулировал запись лога когда через dd на пустом разделе создавал большой файл(больше 3G, sync периодически набирал). После перезагрузки ни осталось ничего, df сообщал отрицательный размер места. После проверки диска вылезли ошибки, файла нет.

да точно такие же там размеры блоков как и при записи без шифрования (кажется 4K). В этом весь смысл блочного шифрования. Попробуй свои "щадящие тесты" на системе без шифрования, результат будет тот же (какая разница какой блок ядро не успело сбросить на диск, зашифрованный или незашифрованный ?!). Шифрация блока по сравнению со временем записи на диск -- практически мговенная операция, подловить не успеешь. Лучше направь свою энергию на absue новых FS типа btrfs и nilfs, результаты здесь выкладывай.

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

Никогда в реальности не видел чтобы после отключения питания ничего не осталось на разделе. Файлы могли покорёжиться и недозаписаться, мог fsck в корку выпасть при проверке диска, приходилось нужные данные из lost+found вытягивать, указывать альтернативный суперблок итп. В общем всегда хотя бы что-то оставалось. А тут пусто, да ещё и занятое место отрицательного размера появилось.

В общем, опасная затея такое на сервере без упса держать.

> Лучше направь свою энергию на absue новых FS типа btrfs и nilfs, результаты здесь выкладывай.

nilfs мне не интересен, а btrfs ещё не скоро до кондиции дойдёт.

В общем я пришёл к выводу что надо dm_crypt надо тока натравливать на те разделы где не будет записи. Для остального надо другие схемы применять. И бэкапить, бэкапить, бэкапить...

мда, щас проблема не воспроизводится. Причём тут я уже питалово вырубаю на БП.

Видимо, это вопрос (не)везения.

> так если на диске будет недозаписанный блок он и останется недозаписанным и в нём будет информация. просто с шифрованием он будет весь инвалидирован, а без шифрования fsck поправит явные ошибки.

размер блока всего 4K, так что разница между шифрованной и нешифрованной ситуацией будет не более чем 4K. Хорошо если это кусок файла. Плохо если это кусок мета-информации (поэтому наверное у тебя отрицательное количество свободных блоков появилось). Но вероятность последнего не так велика, и опять же всё сильно зависит от FS. Так что если тебе интересна надёжность -- используй-таки nilfs (её вообще невозможно убить) и btrfs (у неё есть COW и checksums для данных).

еслиб оно шифрование поддерживало... Я не уверен что btrfs тоже без проблем проглотит выпадание 4к блоков. Всё же это очень приличный объём.