> *** 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 -- оно больше выдаёт метаинформации, согласен > (но, взамен давая "плюшки"). > Да, в этом был вопрос: насколько незашифрованная метаинформация облегчает: - Оффлайновую дешифровку. - Возможность оффлайнового изменения файлов (в т.ч. системных).
