>> Имеет ли смысл? Я планировал установку на SSD. Т.к., SSD достаточно большой, >> там же хочу держать кэш/журналы ZFS, значит требуется два раздела минимум. > > Тогда смысла "чистого" ZFS не имеет конечно же. А вообще есть ли смысл в ZFS на системном SSD?
> Держать кэш на > ненадёжном хранилище можно без проблем, а вот если под журналом вы > подразумеваете ZIL (который "log" в терминах zpool), то его очень > желательно зеркалировать. Ну и иметь в виду, что ZIL/log имеет смысл > только и только для fsync операций: если их мало/нет, то он не даст > ничего. > С кэшэм понятно. А вот насчёт ZIL... Где-то я читал, что выигрыш от переноса журнала на SSD порядка 0.3. Как сбалансировать надёжность хранения журнала и скорость работы с ним? >> В смысле "без предоставления ключа"? Имеется ввиду, что он хранится >> глобально? > > В том смысле, что не делая аналога luksOpen/geli attach, вы всё-равно > сможете делать scrub/resilver/send/recv. Да ну. При хотсвопе это возможно сделать автоматически. Например, для шифрования ключей я использую ключевой файл, который хранится на зашифрованном диске (типичная схема для LUKS с несколькими дисками). Также, есть первичный ключ. Диск в корзину вставляется, udev (условно) запускает хэндлер, который запускает file на устройство, чтобы определить есть ли там шифрование. Затем, если есть, пытается расшифровать. Если нет, автоматически затирает то, что на диске, создавая шифрованный раздел и подключает его в zpool. Если это шифрованный диск, но с другим ключом, может быть выдано предупреждение, используя REST API web интерфейса. Это вкратце. Чем такая схема хуже? > В отличии от полнодискового > шифрования, вы будете знать сколько там реально занято места и размеры > объектов. > Но, фактически, такое шифрование открывает информацию, значит не является надёжным. Потому, остаётся вопрос насчёт geli. На хабре разбирался код ZFS, и там явно видно, что она пытается сделать ioctl, чтобы определить диск/не диск.
