Re: Снова о ZFS
> *** artiom [2018-01-07 21:09]:
>> А вообще есть ли смысл в ZFS на системном SSD?
>
> Ну а почему нет? Вообще почему ZFS может не иметь смысла :-)?
Избыточность и сложность, там где она не нужна.
> Как минимум, бэкапы удобнее делать (snap/send/recv) и проверка целостности.
>
Ok, согласен.
Да, вспомнил тему: солярис использует снэпшоты для отката обновлений.
FreeNAS, как я заметил, тоже.
>> Где-то я читал, что выигрыш от переноса журнала на SSD порядка 0.3.
>
> Всё зависит от режимов работы (fsync).
>
Ну предполагается, что журнал пишется синхронно с записью данных.
>> Как сбалансировать надёжность хранения журнала и скорость работы с ним?
>
> По идее, если понадобился ZIL/log, то просто делают зеркало из него. То
> есть, в идеале, это например просто две SSD в зеркале, отданные от log.
>
Эм... Сейчас у меня только одна SSD и та - системная.
А ведь потеря части ZIL мне грозит лишь частичной потерей последних
транзакций?
>> Да ну. При хотсвопе это возможно сделать автоматически.
>> [...]
>> Чем такая схема хуже?
>
> Всё что вы написали верно. Но всё это подразумевает, что у вас *есть*
> ключ шифрования. Вы не можете отдать ваши диски кому-нибудь чтобы он
> например сделал resilver или scrub или send/recv ваших дисков. Вы не
> можете подключить чужие зашифрованные диски чтобы просто проверить
> scrub-ом их целостность. Мало ли чего бывает. ZFS некоторые задачи по
> обслуживанию может провести без ключа.
>
Достаточно любопытные кейсы, я о таком даже не подозревал.
> Лично я нисколько не призываю к использованию ZFS шифрования из-за этих
> фич. Они не всем нужны. Так как ваш сервер домашний, то ключи наверняка
> всегда, как бы, под рукой и поэтому все эти фишки бесполезны. Я просто
> отметил в чём могут быть плюсы встроенного шифрования.
>
Ok, вас понял. Спасибо.
>> Но, фактически, такое шифрование открывает информацию, значит не
>> является надёжным.
>
> Это всё tradeoff как и в случае с "классическим" полнодисковым
> шифрованием. Например часто используется (ну когда-то, как минимум) CBC
> режим "сливал" данные о конкретном месте с которого началось изменение
> данных в пределах блока жёсткого диска. Да -- это слив данных, но надо
> прикидывать и оценивать чему он может грозить. Большинству пользователей
> он ничему не грозит и поэтому он по-умолчанию повсеместно использовался.
> Для тех кто готов "сливать" только факт изменения всего блока, но не
> конкретной позиции в нём, есть режим EME -- который делает двойное
> шифрование (туда-обратно), что в два раза дороже для CPU, но да --
> надёжнее.
Каким образом он сливал? Вряд ли хранил в незашифрованном журнале.
Я так думаю, что дисковое шифрование нужно для предотвращения
оффлайновых атак, разве нет?
> Или вот GELI/LUKS по-умолчанию не предоставляют никакой
> аутентификации данных, так как это начнёт занимать дополнительное место,
> но тоже не самый безопасный вариант.
В смысле?
> Если вы сделаете GELI/LUKS диск
> поверх чистого, забитого нулями, то, пока полностью весь диск не будет
> записан (хотя бы dd if=/dev/zero of=disk-encrypted), то информация о
> реально используемом месте будет тоже "видна". Везде tradeoff.
>
Это да. Но во-первых, они предлагают сделать перезапись свободного места
перед созданием раздела.
Во-вторых, это даст только сведения о записанном объёме: это почти ничего.
> Это я всё к тому что не стал бы называть ZFS шифрование не надёжным.
> По-сравнению с LUKS/GELI -- оно больше выдаёт метаинформации, согласен
> (но, взамен давая "плюшки").
>
Да, в этом был вопрос: насколько незашифрованная метаинформация облегчает:
- Оффлайновую дешифровку.
- Возможность оффлайнового изменения файлов (в т.ч. системных).
Reply to: