Как задействовать место на загрузочном диске TrueNAS Core

Введение

Поскольку установленная TrueNAS Core (ранее FreeNAS) занимает практически буквально пару гигабайт, то возникает естественное желание задействовать драгоценное место на SSD (а, как мы знаем, лучше даже двух – для зеркалирования). В реальности использовать флешку для загрузки ОС на постоянной основе конечно же не стоит – об этом нас предупреждает установщик, да и вообще. Кстати про реальность – кажется с флешками на 8 гигов (и менее) возможны проблемы, так что лучше с запасом взять на 16 (что мы виртуально и сделаем).

Статья основывается на темах форума по TrueNAS – HOWTO: setup a pair of larger SSDs for boot pool and data (как настроить пару больших SSD для загрузочного пула и данных) и How to setup FreeNAS on a (partitioned) single SSD with boot and jails (как установить FreeNAS на одиночный SSD с разбиением на загрузку и клетки), а также пары статей по FreeBSD как таковой (напомню, что «под капотом» у TrueNAS ни что иное, как именно эта операционная система) - FreeBSD and UEFI Boot (FreeBSD и загрузка через UEFI) и Установка FreeBSD (как ни странно на русском в отличие от всех остальных).

Последние две статьи намекают на то, что в примере мы будем использовать именно загрузку в режиме UEFI, а не BIOS, поскольку полюбившийся мне VirtualBox позволяет загружаться с виртуальных USB и NVMe только таким образом. Кстати будьте внимательны – в интернете (и в частности второй теме форума) чаще подразумевается «старомодный» режим BIOS’а.

TL;DR

Что-то статья получилась весьма и весьма длинной, поэтому если вам не слишком интересно читать про развертывание виртуальной машины, установку TureNAS под UEFI и подробное объяснение, откуда что берется, то можно сразу перейти к разделу «Если применяются два SSD» – там без лишних слов приводится сводка команд. Также хотелось бы анонсировать задачу синхронизации в конце.

Создание виртуальной машины

При написании статьи использовался VirtualBox 6.1.20 с установленным набором расширений – это важно, поскольку именно через этот набор реализуются контроллеры USB 2.0/3.0 и NVMe.

Я предпочитаю «экспертные» режимы. Начало создания виртуальной машины стандартное: тип – BSD, версия FreeBSD (x64), объем памяти не менее 8192 MB.

На втором шаге создается основной диск ВМ. По умолчанию предлагается 16 гигабайт, но давайте поставим 120 и в дальнейшем будем рассматривать этот диск как SSD на NVMe. При «динамическом» формате хранения можно не переживать за место на реальном диске (хоста).

Переходим в настройки вновь созданной машины, вкладку «Система». В настройке материнской платы я обычно меняю чипсет на ICH9, а также включаю «Часы в системе UTC». В обязательном порядке включаем EFI.

Вкладку «Дисплей» пропускаем, переходим к «Носителям» – здесь-то и начинается самое интересное. По умолчанию созданный диск подключается к IDE контроллеру. Добавим NVMe (PCIe) контроллер, перенесем наш диск в него и включим режим твердотельного накопителя.

Добавим контроллер USB и создадим для него диск на 16 гигабайт, на сей раз для имитации «маленькой» флешки для первоначальной установки. Можно установить флаг «С горячей заменой», хотя влияет это наверное только на порядок следования дисков в перечне устройств. Для определенности – я этот флаг взвел.

Добавляем контроллер SCSI или SATA, давайте на сей раз остановимся на AHCI (SATA) как более близкому к «потребительской» платформе. Как обычно, добавляем два или три диска, чтобы TrueNAS не ругался. Объем для наглядности опять же поставим какой-то отличающийся от предыдущих двух, главное чтобы он был одинаковым для всех двух/трех. Сделал три по 500, чтобы мало не показалось.

Аудио отключаем и переходим в «Сеть». Воспользуемся «неразборчивым» режимом сетевого моста, чтобы работал DHCP для клеток (которые jail, напомню, что это «легковесная» виртуализация FreeBSD).

Остальные вкладки можно не трогать, параметры по умолчанию подходят (в частности в разделе USB должен быть включен USB-контроллер 2.0).

Установка TrueNAS Core

На момент написания статьи актуальной версией являлась TrueNAS CORE 12.0-U3 на основе FreeBSD 12.2. Справедливости ради, в апреле 2021 года уже вышла 13.0, слегка отстаем… Запускаем нашу виртуальную машину и попадаем в, не побоюсь этого слова, UEFI Interactive Shell v2.2.

Хм… И что тут делать? Монтируем скачанный ISO-образ на оптический привод (в меню окна виртуальной машины: Устройства – Оптические диски – Выбрать файл диска) и либо перезагружаем машину командой reset, либо выходим в некий «эмулятор BIOS» (штука сама по себе весьма интересная, но заострять на ней внимание не будем) командой exit, а затем возвращаемся в оболочку командой меню Continue либо опять-таки перезагружаем систему (Reset).

Несмотря на то, что вроде бы настроена загрузка с компакт-диска, все равно попадаем в оболочку UEFI, только теперь нам доступна файловая система оптического диска. Переходим в FS1: (именно так и вводим), а далее нам помогут «традиционные» команды dir и cd. В конечном итоге нам надо запустить bootx64.efi из \efi\boot. На скриншоте показан «подробный» путь к нужному файлу (на тот случай, если вдруг что-то изменится в последующих релизах).

Но вообще можно было бы сразу после перехода в FS1: запустить \efi\boot\bootx64.efi (обратите внимание – используются обратные слэши).

Начнется загрузка установщика, сначала появится меню, в котором в принципе особо ничего и не надо делать (можно нажать Enter, чтобы сэкономить несколько секунд). Вот оно, для контроля:

А затем мы наконец попадем собственно в программу установки. Сама по себе процедура установки достаточно обыденная (описываю сокращенно) – выбираем нашу флешку в качестве диска для установки:

При нашей настройке виртуальной машины ее определить очень просто – не только по размеру, но и по названию: SATA-шные (и IDE) диски называются ada; NVMe – nvd; SCSI и, как видим, USB – просто da. Модель, к сожалению, в VirtualBox одна – VBOX HARDDISK (за исключением NVMe), что таки слегка сбивает с толку.

На следующем шаге подтверждаем установку на выбранный диск (da0 в нашем случае). В диалоговом окне как раз говорится о том, о чем я в немалой степени говорил в начале: систему не рекомендуется устанавливать на флешки и вы не сможете использовать этот диск для пользовательских данных (позволю себе так перевести «You can’t use da0 for sharing data»). Также нас предупреждают об удалении всех разделов и данных с диска.

После подтверждения установки задаем пароль root и наконец выбираем загрузку по UEFI:

Что ж, осталось дождаться завершения установки. FreeBSD сама по себе как-то довольно медленно эмулируется, а тут еще и USB, так что времени процесс займет намного дольше, чем в случае стандартной установки в режиме BIOS на IDE-контроллер. После вывода сообщения об успехе возвращаемся в начальное меню.

В нем, соответственно, нужно выбрать Reboot System. При этом нужно умудриться вовремя виртуально извлечь комакт-диск (примерно когда секунду-другую висит черный экран, как я полагаю — хотя проще наверное нажать Esc когда идет обратный отсчет, спокойно «изъять диск из привода» и сделать reset), иначе есть опасность, что загрузка теперь пойдет автоматически с привода (где он раньше был, спрашивается), а не с виртуальной флешки. Отличить их можно по загрузочному меню – одно я показывал ранее на скриншоте (и называется TrueNAS Installer), а другое называется Welcome to TrueNAS и состав пунктов слегка отличается.

Дожидаемся генерации неких параметров DH, после чего наконец-то системой можно начинать пользоваться.

Напомню, что первым делом желательно перейти в раздел System – General, где нужно будет указать правильную временную зону и отключить сбор телеметрии. На свой страх и риск можно выбрать заодно и русский язык, но из-за неполного перевода на мой взгляд лучше так не делать.

Народ на форумах рекомендует также включить SSH, хотя отчасти это не обязательно – есть веб-консоль, да и окно самой виртуальной машины никто не отменял. Хотя «родным» PuTTY пользоваться удобнее, особенно Midnight Commander’ом, который любезно предустановлен разработчиками.

Итак, в разделе Services сначала в настройках сервиса SSH разрешаем вход под root по паролю (Log in as Root with Password), а затем включаем сервис и делаем загрузочным (Start Automatically).

 

На этом будем считать установку системы завершенной.

Клонирование флешки на SSD

Потихоньку подбираемся к тому, ради чего мы здесь собственно и собрались – взяв за основу нашу «маленькую» флешку, сделать ее клон на SSD. Внимание! В любом случае подобные «финты ушами» не являются поддерживаемыми TrueNAS, а если проводить подобные манипуляции в реальности, то в случае ошибки можно уничтожить данные.

Проверка состава дисков

Почти все операции проводятся в консоли, в немалой степени ради этого в предыдущем разделе включали SSH. Для начала еще раз перепроверим, где какой диск. Понятно, что их список был выведен в процессе установки, но мало ли. К примеру можно вернуться к веб-интерфейсу: Storage – Disks.

Если же говорить о консоли, то:

# geom disk list

Пример вывода для виртуальной машины:

root@truenas[~]# geom disk list
Geom name: nvd0
Providers:
1. Name: nvd0
   Mediasize: 128849018880 (120G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: ORCL-VBOX-NVME-VER12
   lunid: 3660c1d85dfc854f8598698c7c9faf84
   ident: VB1234-56789
   rotationrate: 0
   fwsectors: 0
   fwheads: 0

Geom name: cd0
Providers:
1. Name: cd0
   Mediasize: 0 (0B)
   Sectorsize: 2048
   Mode: r0w0e0
   descr: VBOX CD-ROM
   ident: (null)
   rotationrate: unknown
   fwsectors: 0
   fwheads: 0

Geom name: ada0
Providers:
1. Name: ada0
   Mediasize: 536870912000 (500G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: VBOX HARDDISK
   ident: VBcd896337-0fff11f0
   rotationrate: unknown
   fwsectors: 63
   fwheads: 16

Geom name: ada1
Providers:
1. Name: ada1
   Mediasize: 536870912000 (500G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: VBOX HARDDISK
   ident: VBfdb0b20d-54b78a8e
   rotationrate: unknown
   fwsectors: 63
   fwheads: 16

Geom name: ada2
Providers:
1. Name: ada2
   Mediasize: 536870912000 (500G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: VBOX HARDDISK
   ident: VB2295d677-41b6ce8d
   rotationrate: unknown
   fwsectors: 63
   fwheads: 16

Geom name: da0
Providers:
1. Name: da0
   Mediasize: 17179869184 (16G)
   Sectorsize: 512
   Mode: r1w1e2
   descr: VBOX HARDDISK
   ident: (null)
   rotationrate: unknown
   fwsectors: 63
   fwheads: 255

Эмм, какие-то геомы, провайдеры… В официальной документации GEOM названа модульной инфраструктурой преобразования дисковых запросов, что как-то не проясняет ситуацию! Но в нашем простейшем случае разобраться несложно, поскольку видим только по одному провайдеру на каждое имя.

Итак, сверим часы: флешка - da0, SSD – nvd0.

Подготовка SSD

Посмотрим текущее состояние таблиц разделов:

# gpart show

Пример вывода:

root@truenas[~]# gpart show
=>      40  33554352  da0  GPT  (16G)
        40    532480    1  efi  (260M)
    532520  32997376    2  freebsd-zfs  (16G)
  33529896     24496       - free -  (12M)

Как видим, на данный момент таблица разделов (GPT) существует только на устройстве da0. В упор не понимаю, зачем установщик выделил под раздел efi аж 260 мегабайт, ну да ладно.

Кстати мы же можем посмотреть содержимое этого раздела:

root@truenas[~]# cd /media
root@truenas[/media]# mkdir efi
root@truenas[/media]# mount -t msdosfs /dev/da0p1 /media/efi
root@truenas[/media]# cd efi
root@truenas[/media/efi]# ls -Rl ./
total 16
drwxr-xr-x  1 root  wheel  16384 Apr 26 13:35 efi

./efi:
total 16
drwxr-xr-x  1 root  wheel  16384 Apr 26 13:35 boot

./efi/boot:
total 112
-rwxr-xr-x  1 root  wheel  94208 Apr 26 13:35 BOOTx64.efi
-rwxr-xr-x  1 root  wheel     12 Apr 26 13:35 startup.nsh
root@truenas[/media/efi]# cd ~
root@truenas[~]# umount /media/efi

Да уж, какие-то жалкие два файла на 100 килобайт. Ладно, едем дальше, и тут-то как раз начинаются деструктивные операции.

Если вдруг на ssd уже есть какая-то таблица разделов, то удалим ее:

# gpart destroy -F nvd0

Копируем таблицу разделов с флешки на SSD:

# gpart backup da0 | gpart restore nvd0

Еще раз обращаю внимание на имена устройств: backup с флешки, restore на ssd. Проверяем:

root@truenas[~]# gpart backup da0 | gpart restore nvd0
root@truenas[~]# gpart show
=>      40  33554352  da0  GPT  (16G)
        40    532480    1  efi  (260M)
    532520  32997376    2  freebsd-zfs  (16G)
  33529896     24496       - free -  (12M)

=>       40  251658160  nvd0  GPT  (120G)
         40     532480     1  efi  (260M)
     532520   32997376     2  freebsd-zfs  (16G)
   33529896  218128304        - free -  (104G)

Отлично, теперь необходимо сделать SSD загрузочным. Два варианта: скопировать раздел efi командой dd либо прописать загрузчик с помощью gpart bootcode.

# dd if=/dev/da0p1 of=/dev/nvd0p1 bs=1M

На всякий случай напомню, что if – источник, of – приемник, bs – размер блока. Последний параметр указать очень важно, иначе копирование будет происходить крайне медленно. В примере используются блоки по 1 мегабайту.

root@truenas[~]# dd if=/dev/da0p1 of=/dev/nvd0p1 bs=1M
260+0 records in
260+0 records out
272629760 bytes transferred in 48.835848 secs (5582574 bytes/sec)

В любом случае gpart работает как-то быстрее:

# gpart bootcode -p /boot/boot1.efifat -i 1 nvd0

Во FreeBSD есть заранее подготовленный образ EFI-загрузчика, это как раз файл /boot/boot1.efifat, указанный в параметре -p. Об этом можно узнать, видимо, из man uefi, поскольку man gpart подробно расписывает только вариант с BIOS (а то еще и MBR вдобавок). Хотя нашлось упоминание и в документации (примечание к разделу 20.3.11). Оставшиеся параметры говорят о том, что загрузчик надо записать в первый раздел устройства (геома) nvd0.

Пример вывода:

root@truenas[~]# gpart bootcode -p /boot/boot1.efifat -i 1 nvd0
partcode written to nvd0p1

Перенос загрузочного пула

Теперь начинается, пожалуй, самое интересное: делаем загрузочный пул зеркалом, а затем удаляем из него флешку. Сначала выведем список пулов ZFS:

# zpool list

В виртуальной машине на данный момент он всего один и называется boot-pool:

root@truenas[~]# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
boot-pool  15.5G  1.16G  14.3G        -         -     0%     7%  1.00x    ONLINE  -

Проверим состояние (zpool status [pool]):

root@truenas[~]# zpool status boot-pool
  pool: boot-pool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        boot-pool   ONLINE       0     0     0
          da0p2     ONLINE       0     0     0

errors: No known data errors

Как и следовало ожидать, загрузочный пул работает на da0p2 (вспомним gpart show – раздел 2 на устройстве da0). Преобразовываем пул в зеркало из da0p2 и nvd0p2:

# zpool attach boot-pool da0p2 nvd0p2

Меня немного смущало указание имеющегося устройства, но таков синтаксис команды.

Проверяем (я не указываю пул при получении статуса, поскольку он один):

root@truenas[~]# zpool attach boot-pool da0p2 nvd0p2
root@truenas[~]# zpool status
  pool: boot-pool
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Apr 26 17:10:21 2021
        1.16G scanned at 10.7M/s, 407M issued at 3.67M/s, 1.16G total
        405M resilvered, 34.20% done, no estimated completion time
config:

        NAME        STATE     READ WRITE CKSUM
        boot-pool   ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            da0p2   ONLINE       0     0     0
            nvd0p2  ONLINE       0     0     0  (resilvering)

errors: No known data errors

Процесс, как говорится, пошел. Меня вновь смущало слово resilvering, но используется именно такой термин. Можно заняться какими-то другими делами, периодически опрашивая статус, пока пул не приобретет примерно следующий вид:

root@truenas[~]# zpool status
  pool: boot-pool
 state: ONLINE
  scan: resilvered 1.19G in 00:04:47 with 0 errors on Mon Apr 26 17:15:08 2021
config:

        NAME        STATE     READ WRITE CKSUM
        boot-pool   ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            da0p2   ONLINE       0     0     0
            nvd0p2  ONLINE       0     0     0

errors: No known data errors

Теперь можем удалить флешку из пула:

# zpool detach boot-pool da0p2

На форумах зачем-то перед этим переводят da0p2 в оффлайн, но этого не следует ни из man zpool-deatch (где предлагается использовать offline вместо detach, если нужно временно отключить диск), ни из моих испытаний перед написанием статьи (zpool status все равно показывал online).

Проверяем:

root@truenas[~]# zpool detach boot-pool da0p2
root@truenas[~]# zpool status
  pool: boot-pool
 state: ONLINE
  scan: resilvered 1.19G in 00:04:47 with 0 errors on Mon Apr 26 17:15:08 2021
config:

        NAME        STATE     READ WRITE CKSUM
        boot-pool   ONLINE       0     0     0
          nvd0p2    ONLINE       0     0     0

errors: No known data errors

Создание пула на свободном месте

Осталось задействовать свободное место на SSD. Создаем раздел с параметрами по умолчанию:

# gpart add -t freebsd-zfs -l ssd0 nvd0

На всякий случай присвоил метку ssd0 (параметр -l). Параметр -t определяет тип файловой системы, ну а в конце – наш любимый геом (диск).

Пример вывода:

root@truenas[~]# gpart add -t freebsd-zfs -l ssd0 nvd0
nvd0p3 added

Прежде чем создавать новый пул, необходимо узнать GUID созданного раздела. Честно говоря, даже немного странно, что загрузочный пул установщик создает на именах разделов типа da0p2, а пулы для данных – на gptid. Возможно изменение размещения загрузочного диска представляется намного менее вероятным, чем устройств для хранения данных. Хотя для проверки в виртуальной машине я легким движением руки перенес «SSD» в IDE-контроллер, и все загрузилось. Немного отвлеклись – для определения GUID’ов воспользуемся командой gpart list:

# gpart list nvd0

Пример вывода:

root@truenas[~]# gpart list nvd0
Geom name: nvd0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 251658199
first: 40
entries: 128
scheme: GPT
Providers:
1. Name: nvd0p1
   Mediasize: 272629760 (260M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   efimedia: HD(1,GPT,6a48fe3b-a696-11eb-a80c-0800270ddf06,0x28,0x82000)
   rawuuid: 6a48fe3b-a696-11eb-a80c-0800270ddf06
   rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
   label: (null)
   length: 272629760
   offset: 20480
   type: efi
   index: 1
   end: 532519
   start: 40
2. Name: nvd0p2
   Mediasize: 16894656512 (16G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 272650240
   Mode: r1w1e1
   efimedia: HD(2,GPT,6a4958c7-a696-11eb-a80c-0800270ddf06,0x82028,0x1f78000)
   rawuuid: 6a4958c7-a696-11eb-a80c-0800270ddf06
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 16894656512
   offset: 272650240
   type: freebsd-zfs
   index: 2
   end: 33529895
   start: 532520
3. Name: nvd0p3
   Mediasize: 111681691648 (104G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 4282404864
   Mode: r0w0e0
   efimedia: HD(3,GPT,3a94404d-a69b-11eb-a80c-0800270ddf06,0x1ffa028,0xd005fb0)
   rawuuid: 3a94404d-a69b-11eb-a80c-0800270ddf06
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: ssd0
   length: 111681691648
   offset: 17167306752
   type: freebsd-zfs
   index: 3
   end: 251658199
   start: 33529896
Consumers:
1. Name: nvd0
   Mediasize: 128849018880 (120G)
   Sectorsize: 512
   Mode: r1w1e2

Как видим, вывод достаточно большой (опять же проявляется польза от PuTTY, кстати веб-консоль плохо работает с буфером обмена), из всего этого благополучия нам требуется значение rawuuid 3-го раздела:

3. Name: nvd0p3
   …
   rawuuid: 3a94404d-a69b-11eb-a80c-0800270ddf06

В вашем случае он разумеется будет другим. Итак, зная GUID раздела, создаем на нем пул под названием ssd (для примера):

# zpool create ssd gptid/3a94404d-a69b-11eb-a80c-0800270ddf06

Проверяем:

root@truenas[~]# zpool create ssd gptid/3a94404d-a69b-11eb-a80c-0800270ddf06
root@truenas[~]# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
boot-pool  15.5G  1.16G  14.3G        -         -     0%     7%  1.00x    ONLINE  -
ssd         104G   100K   104G        -         -     0%     0%  1.00x    ONLINE  -
root@truenas[~]# zpool status ssd
  pool: ssd
 state: ONLINE
config:

        NAME                                          STATE     READ WRITE CKSUM
        ssd                                           ONLINE       0     0     0
          gptid/3a94404d-a69b-11eb-a80c-0800270ddf06  ONLINE       0     0     0

errors: No known data errors

Отлично, для пущей важности отмонтируем новый пул, удалим директорию (чтобы не мешалась) и экспортируем его (хотя вроде бы это не обязательно – импорт в веб-интерфейс выполнялся и так).

root@truenas[~]# umount /ssd
root@truenas[~]# rmdir /ssd
root@truenas[~]# zpool export ssd

Что интересно, после команды экспорта пул пропадает из списка:

root@truenas[~]# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
boot-pool  15.5G  1.16G  14.3G        -         -     0%     7%  1.00x    ONLINE  -

Вроде бы на этом почти все, выключаем машину:

# poweroff

В настройках виртуальной машины удаляем USB-контроллер из накопителей, а также отключаем USB на одноименной вкладке.

 

Если все сделано правильно, машина должна стартовать «как ни в чем ни бывало».

Если применяются два SSD

В этом случае большинство вышеуказанных команд надо повторять дважды для каждой SSD: очистить таблицу разделов (повторюсь, при наличии), склонировать, записать загрузчик:

# gpart destroy -F nvd0
# gpart destroy -F nvd1
# gpart backup da0 | gpart restore nvd0
# gpart backup da0 | gpart restore nvd1
# gpart bootcode -p /boot/boot1.efifat -i 1 nvd0
# gpart bootcode -p /boot/boot1.efifat -i 1 nvd1

Пул преобразовывать, как ни странно, тоже нужно поэтапно (я почему-то первоначально думал, что тройное зеркало можно сделать одной командой):

# zpool attach -w boot-pool da0p2 nvd0p2
# zpool attach -w boot-pool da0p2 nvd1p2

Я добавил опцию -w, чтобы сразу же дождаться этого самого resilvering. Хотя конечно же опросить состояние в любом случае не повредит.

Исключение флешки, очевидно, делается однократно:

# zpool detach boot-pool da0p2

Вновь дважды создаем разделы на свободных местах:

# gpart add -t freebsd-zfs nvd0
# gpart add -t freebsd-zfs nvd1

И создаем зеркальный пул на созданных разделах (получаем GUID’ы командой gpart list). Как видите, после имени пула добавил слово mirror, иначе создалось бы «линейное» объединение (stripe) дисков.

# zpool create ssd mirror gptid/f91a81d6-a914-11eb-9fd6-080027a663cc gptid/fa35b9dd-a914-11eb-9fd6-080027a663cc

Очистка и экспорт ради приличия:

# umount /ssd
# rmdir /ssd
# zpool export ssd

Завершение настройки в веб-интерфейсе

Переходим в раздел Storage – Pools, он скорее всего будет пустым. Сначала предлагаю импортировать пул, созданный нами на SSD. Добавляем пул (Add), на первом шаге выбираем «Import an existing pool», на втором оставляем вариант по умолчанию – No, continue with import (мы же ведь не шифровали ничего), на третьем выбираем ssd (в соответствии с тем, как он был назван командой zpool create), и на последнем шаге (забыл сделать скриншот) подтверждаем импорт (Import).

 

Поскольку при создании пула не использовались какие-либо дополнительные параметры, то сжатие отключено. Дедупликацию по большому счету лучше вообще никогда не включать (если только речь не идет о реально каких-то промышленных установках).

В настройках пула можно, к примеру, отключить Atime (обновление времени доступа к файлам, т.е. отключение по идее должно благотворно сказаться на ресурсе SSD) и включить сжатие (LZ4 по умолчанию, впрочем смотря что предполагается на этом пуле хранить – может ZLE в каких-то случаях типа h264/ac3 окажется уместнее).

С импортированным пулом обнаружился нюанс. Прежде чем сохранять настройки, нужно раскрыть Advanced options и установить ACL Mode – Passthrough. Поскольку изначально никакого значения там не установлено, это приводит к ошибке при сохранении.

Теперь стандартным образом создаем «основной» пул из подготовленных SATA-дисков. На первом шаге выберем (фактически оставим) Create New Pool, в окне Pool Manager нажимаем Suggest Layout, на трех дисках создастся Raid-z (что и предполагалось). Имя пусть будет традиционным для TrueNAS – tank.

Итак, должно получиться примерно следующее:

Сравним с консолью:

root@truenas[~]# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
boot-pool  15.5G  1.16G  14.3G        -         -     0%     7%  1.00x    ONLINE  -
ssd         104G  94.8M   104G        -         -     0%     0%  1.00x    ONLINE  /mnt
tank       1.45T   768K  1.45T        -         -     0%     0%  1.00x    ONLINE  /mnt

Хочу обратить внимание на то, что веб-интерфейс присвоил пулам так называемый ALTROOT. На прикладном уровне это означает, что «точки монтирования» находятся внутри /mnt, т.е. /mnt/ssd и /mnt/tank соответственно. Еще почему-то неправильно вывелся размер «танка», веб-интерфейс показывает более реалистичную цифру.

root@truenas[~]# zpool status
  pool: boot-pool
 state: ONLINE
  scan: resilvered 1.19G in 00:04:47 with 0 errors on Mon Apr 26 17:15:08 2021
config:

        NAME        STATE     READ WRITE CKSUM
        boot-pool   ONLINE       0     0     0
          nvd0p2    ONLINE       0     0     0

errors: No known data errors

  pool: ssd
 state: ONLINE
config:

        NAME                                          STATE     READ WRITE CKSUM
        ssd                                           ONLINE       0     0     0
          gptid/3a94404d-a69b-11eb-a80c-0800270ddf06  ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: ONLINE
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz1-0                                      ONLINE       0     0     0
            gptid/5083b011-a6a6-11eb-b83f-0800270ddf06  ONLINE       0     0     0
            gptid/5090d879-a6a6-11eb-b83f-0800270ddf06  ONLINE       0     0     0
            gptid/509a7fa4-a6a6-11eb-b83f-0800270ddf06  ONLINE       0     0     0

errors: No known data errors

Хочу поделиться «приколом». Как вы наверняка заметили, swap-раздел на установочном диске отсутствовал, так вот судя по всему веб-интерфейс создает разделы подкачки на дисках для данных при создании основного пула.

oot@truenas[~]# gpart show
=>       40  251658160  nvd0  GPT  (120G)
         40     532480     1  efi  (260M)
     532520   32997376     2  freebsd-zfs  (16G)
   33529896  218128304     3  freebsd-zfs  (104G)

=>        40  1048575920  ada2  GPT  (500G)
          40          88        - free -  (44K)
         128     4194304     1  freebsd-swap  (2.0G)
     4194432  1044381528     2  freebsd-zfs  (498G)

=>        40  1048575920  ada1  GPT  (500G)
          40          88        - free -  (44K)
         128     4194304     1  freebsd-swap  (2.0G)
     4194432  1044381528     2  freebsd-zfs  (498G)

=>        40  1048575920  ada0  GPT  (500G)
          40          88        - free -  (44K)
         128     4194304     1  freebsd-swap  (2.0G)
     4194432  1044381528     2  freebsd-zfs  (498G)

Причем swap отзеркаленный.

root@truenas[~]# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/mirror/swap0.eli   2097152        0  2097152     0%

Репликация пула ssd

Если не путаю, на форумах было предложено делать периодические бэкапы SSD-пула на основной. Давайте так и поступим, но прежде надо сказать пару слов о снимках, поскольку система репликации в конечном итоге основана на них. Снимок можно представить как копию файловой системы, хотя есть пример сравнения снимка с некоей ссылкой на версию данных. На файловых системах типа copy-on-write снимки создаются очень быстро, однако при этом возникает такой нюанс: если вы удаляете файл, который есть в снимке, свободное место не высвобождается, нужно удалить все снимки, в которые входил удаленный файл.

Возвращаясь к резервному копированию, для начала создадим так называемый датасет (dataset) – если совсем уж на пальцах, его можно представить как продвинутую директорию – на основном пуле в качестве места назначения (Storage – Pools, меню пула – Add Dataset). К примеру назовем его ssd_backup, настройки в принципе можно не трогать (разве что сжатие переопределить, если установленное на уровне всего пула не подходит).

Добавляем задачу репликации (Tasks – Replication Tasks, Add). Source Location (источник): On this System (на этой системе), ssd. Destination Location (назначение): On this System (на этой системе), tank/ssd_backup.

Описание флага Recursive несколько вводит в заблуждение – в нем говорится о снимках, но по факту если внутри источника есть вложенные датасеты, то флаг нужно взводить.

На втором шаге предлагается настроить расписание, по умолчанию ежедневно в полночь (Daily). Также есть варианты Hourly (ежечасно), Weekly (по воскресеньям) и Monthly (ежемесячно). Конечно же можно указать и собственное расписание, однако для теста я выберу ежечасную репликацию. Получается как-то так: Replication Schedule – Run On a Schedule (запуск по расписанию), Destination Snapshot Lifetime – Same as Source, т.е. время жизни снимков будет совпадать с исходным (по умолчанию используется две недели).

Я нажал Run now, вроде что-то нареплицировал.

Задача репликации создала в свою очередь задачу периодического создания снимков (snapshot). Повторный ручной запуск задачи репликации уже ни к чему не приведет, поскольку новых снимков нет. Так что для проверки нужно будет создать какой-нибудь файл и дождаться начала следующего часа.

Список снимков находится в Storage – Snapshots, имеются команды удаления, клонирования снимка в новый датасет и отката.

Последний штрих, что называется – теперь при желании можно использовать пул ssd для размещения клеток (jail) и плагинов (которые по сути преднастроенные jail). При первом переходе в любой из этих разделов (т. е. Plugins или Jails) будет запрошен выбор пула. Укажем ssd:

В результате всех настроек наши пулы приобретают следующий вид:

Что интересно, ssd_backup переведен в режим «только чтение». Вот теперь, пожалуй, все.

Заключение

Очень жаль, что для казалось бы элементарного действия – разбиения загрузочного диска – приходится выполнять столь изощренную процедуру. Хотелось бы конечно пожелать добавить подобный функционал в установщик, но увы. Вероятность этого «крайне мала» ©. Стоит ли заморачиваться? Если найдется «маленький» SSD, то может быть и нет. А вот на относительно большом велик соблазн использовать клетки и/или плагины и тогда уже придется пуститься во все тяжкие… Будьте внимательны и не уничтожте случайно данные.