/boot на ZFS зеркале

[13werwolf13]

ну с легаси то всё понятно, а с ефи как быть? /boot/efi должен лежать на fat32/efs разделе, как его зеркалить без костылей?

[artiom_n]

1. Если также выносить /boot на отдельный раздел, это не столь актуально, потому не делать. EFI раздел будет обновляться не так часто, и возможно иметь две копии, синхронизируемые вручную, либо скриптом.
2. Чисто технически сделать это возможно. Видимо, у них это обрабатывается уже ОС, а загрузочных записей там две.
3. Это возможно сделать и в Linux, но путём определённых приседаний.
4. Вероятно, это возможно сделать, зная где device mapper располагает метаданные (EFI should be able to handle RAID paritions, but only with metadata <= 1.0. Newer version of metadata are stored on the beginning of the partition (screwing up the filesystem detection)), что опасно и в какой-то мере является костылём (и не всегда работает: "I tried mdraid, but even with metadata 1.0 the fat filesystem can't be direct mounted.").

[skeletor]

Когда пишите, ashift=12 — вы уверенны, что ваш HDD/SSD/… поддерживает блоки 4к (даже enterprise диски не все это поддерживают)? И в статье даже нет никаких упоминаний, что за параметры. В предыдущей статье тоже самое, просто записан параметр без объяснений.

[artiom_n]

Хорошо, что вы заметили. Добавил примечание.
Тем не менее, позволю себе сослаться на man zpool.

И на мануал, ссылка на который есть в предыдущей:

The use of ashift=12 is recommended here because many drives today have 4KiB (or larger) physical sectors, even though they present 512B logical sectors. Also, a future replacement drive may have 4KiB physical sectors (in which case ashift=12 is desirable) or 4KiB logical sectors (in which case ashift=12 is required).

И он явно рекомендуется к прочтению.
Я так понимаю, большинство дисков сейчас выпускаются с поддержкой 4K блоков, а пользователь, который хочет знать, что делают параметры, может посмотреть man.
Да, недоработка была, но по выше указанным причинам, не критичная.

[skeletor]

Ошибаетесь. Недоработка — достаточно критическая. Если неправильно выбрать размер блока, возможна деградация по скорости записи/чтения на диск (но если для вас это не критично, то мне больше нечего сказать). Более того, как раз наоборот, дисков с поддержкой 4к гораздо меньше, чем с 512. Да и значение «many» из man'a не означает большинство.

PS. Отсылка к man'y вообще не уместна, учитывая уровень статьи.

[artiom_n]

Ok. Примечание добавлено.
Размер дискового сектора сейчас стремится соответствовать "типичному" размеру страницы в 4K, и переход на него начался с 2009-го года, уже почти 10 лет как.
И такой размер сектора у новых HDD.
Не буду говорить за все новые HDD, т.к. не знаю, но буду благодарен, если вы приведёте примеры с другим размером сектора (я видел только с 4K).

P.S.:
Отсылка к man по моему мнению уместна всегда.
Параметров много, я не могу описывать каждый, который и так описан в документации.
В случае с ashift я с вами согласен: недоработка есть, потому я внёс в статью примечание.

[skeletor]

Без проблем. Вот из новых:

HUC156060CSS20x
HUC156045CSS20x
HUC156030CSS20x

HUH721010AL4204

ST12000NM0017
ST12000NM0037
ST12000NM0137
ST12000NM0147

ST8000NM0075

Стремится, не значит — что уже есть. Да, с каждым днём/годом, всё больше и больше, но пока не настолько сильно, что бы пренебрегать 512. Вот начитаются статей неопытные, будут тормоза, и будут потом хаять zfs, мол медленная. И найти проблему будет потом не просто.

[artiom_n]

HUH721010AL4204, ST8000NM0075 и ST12000NM* — это всё-таки гелиевые диски на 8, 10, 12+ ТБ, и у них "переменный размер сектора", т.к. 512 байт просто неэффективно и оставлено для совместимости.
512e — не физический размер, это аппаратная эмуляция размера сектора 512 байт, при размере сектора на диске в 4K.

Про высокооборотистые SAS-ы я вижу, забыл совсем: не приходится с ними сталкиваться.
Да тут вы правы, с той оговоркой, что неопытные с ними не работают, как правило.

Вот начитаются статей неопытные, будут тормоза, и будут потом хаять zfs, мол медленная. И найти проблему будет потом не просто.

Ok. Принимается.

[artiom_n]

Да, и всё-таки для /boot раздела размером порядка 1 ГБ просадка производительности не критична, но в предыдущую статью я добавил расширенный комментарий.

[artiom_n]

Приведу тут также картинку из статьи, упомянутой выше (15K SAS это не касается, естественно):

[skeletor]

del