*** 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
