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