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


    Небольшая заметка, в дополнение к статье о корневом разделе на ZFS.


    В предыдущей статье /boot был продублирован на двух ext4 разделах, и в будущем планировалось сделать нормально.


    Ядро обновляется достаточно часто и каждый раз приходилось монтировать оба /boot, обновлять ядро, копировать содержимое, делать update-grub, update-initramfs и т.п..


    Это порядком надоело.


    Будущее настало.


    Возможно сделать это скриптом, но grub2 поддерживает загрузку с ZFS.


    Потому, правильный и менее затратный вариант — это сделать /boot на ZFS зеркале. Предполагается, что условия те же, что описаны в предыдущей статье: Debian, root на ZFS.


    Предварительные шаги


    Необходимо скопировать образы разделов, например на флешку, чтобы в случае неудачи, возможно было восстановиться к предыдущему рабочему состоянию:


    mount /dev/disk/by-id/usb-Corsair_Flash_Voyager-0\:0-part1 /mnt/usb/
    dd if=/dev/disk/by-id/ata-Micron_1100-part2 of=/mnt/usb/micron_boot.img bs=4M
    dd if=/dev/disk/by-id/ata-Samsung_SSD_850_PRO-part2 of=/mnt/usb/samsung_boot.img bs=4M
    umount /mnt/usb

    Обязательно извлеките флешку из USB после этого.


    Надо проверить загружается ли модуль zfs в grub:


    grep -R zfs /boot/grub/grub.cfg 

    В результате должна быть выведена строка insmod zfs.
    Если её там нет, надо добавить такую строку в /etc/default/grub:


    GRUB_PRELOAD_MODULES="zfs"

    В принципе, grub сам добавит нужный модуль, когда обнаружит установку на ZFS, но лучше перестраховаться.


    Теперь потребуется скопировать содержимое загрузочного раздела, которое потребуется в будущем:


    mount /dev/disk/by-id/ata-Micron_1100-part2 /boot
    tar -C / -cf ~/boot.tar /boot
    tar tf ~/boot.tar

    В результате, на экран должен быть выведен список файлов из /boot.


    Теперь ФС возможно отмонтировать:


    umount /boot

    Создание ZFS пула и загрузочной ФС


    rm -rf /boot
    zpool create -f -o ashift=12 \
      -O atime=off -O compression=lz4 -O normalization=formD \
      -O mountpoint=none \
      boot_pool mirror /dev/disk/by-id/ata-Micron_1100-part2 /dev/disk/by-id/ata-Samsung_SSD_850_PRO-part2
    zfs create -o mountpoint=/boot boot_pool/boot
    zpool set bootfs=boot_pool/boot boot_pool
    zfs mount|grep /boot

    Примечание о параметре ashift

    ashift — степень, в которую надо возвести двойку, чтобы получить указанный размер блока.
    12 — это блок 4K.
    Получить размер блока возможно командой blockdev --getbsz /dev/<disk>, либо из технической спецификации на устройство.


    Если в результате, появится строка boot_pool /boot, пул был создан корректно, а dataset примонтирован.


    zpool list boot_pool  -v

    Должен вывести что-то подобное:


    NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
    boot_pool  1008M   220M   788M         -     7%    21%  1.00x  ONLINE  -
      mirror  1008M   220M   788M         -     7%    21%
        /dev/disk/by-id/ata-Micron_1100-part2      -      -      -         -      -      -
        /dev/disk/by-id/ata-Samsung_SSD_850_PRO-part2      -      -      -         -      -      -

    Установка загрузчика


    Предварительно надо проверить, что grub понимает ФС:


    grub-probe /boot

    Должна быть выведена строка zfs.


    tar -C / -xf ~/boot.tar
    ls /boot

    После завершения распаковки на экран будет выведен список файлов в /boot.


    Далее, обновление initramfs и установка загрузчика:


    update-initramfs -k all -u
    grub-install --bootloader-id=debian1 --recheck --no-floppy /dev/disk/by-id/ata-Samsung_SSD_850_PRO
    grub-install --bootloader-id=debian2 --recheck --no-floppy /dev/disk/by-id/ata-Micron_1100
    ZPOOL_VDEV_NAME_PATH=YES update-grub

    Процесс займёт некоторое время. Загрузчик, по-идее возможно не переустанавливать, но у меня без этого не заработало.


    Теперь надо перезагрузиться:


    reboot

    После перезагрузки zfs mount|grep /boot выведет boot_pool/boot /boot, что означает: всё прошло корректно.


    Если что-то пошло не так


    Достаточно загрузиться с Live USB и скопировать один из образов обратно:


    mount /dev/disk/by-id/usb-Corsair_Flash_Voyager-0\:0-part1 /mnt/usb/
    dd if=micron_boot of=/dev/disk/by-id/ata-Micron_1100-part2 bs=4M
    umount /boot

    После этого возможно грузиться с восстановленного загрузочного раздела.

    Поделиться публикацией
    Комментарии 11
      0
      ну с легаси то всё понятно, а с ефи как быть? /boot/efi должен лежать на fat32/efs разделе, как его зеркалить без костылей?
        0
        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.").
          0
          Когда пишите, ashift=12 — вы уверенны, что ваш HDD/SSD/… поддерживает блоки 4к (даже enterprise диски не все это поддерживают)? И в статье даже нет никаких упоминаний, что за параметры. В предыдущей статье тоже самое, просто записан параметр без объяснений.
            0

            Хорошо, что вы заметили. Добавил примечание.
            Тем не менее, позволю себе сослаться на 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.
            Да, недоработка была, но по выше указанным причинам, не критичная.

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

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

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


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

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

                  HUC156060CSS20x
                  HUC156045CSS20x
                  HUC156030CSS20x

                  HUH721010AL4204

                  ST12000NM0017
                  ST12000NM0037
                  ST12000NM0137
                  ST12000NM0147

                  ST8000NM0075

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

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


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


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

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

                      0

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

                        0

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

                0
                del

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое