Расширил RAIDZ1 пятым диском без пересборки пула — отчёт и грабли

[nyrob]

Долгожданное случилось: расширил домашний RAIDZ1 на живую, без бэкапа-пересборки. Делюсь, пока горячо.

Исходные данные: TrueNAS SCALE 25.04, пул из 4×8 ТБ WD (перемаркированные white label с барахолки, брал по 14 тыс ₽), занято 19 из 21 ТиБ — притык. Докинул пятый такой же, дальше одна команда (в GUI есть кнопка Extend, но руками понятнее, что происходит):

zpool attach tank raidz1-0 /dev/disk/by-id/wwn-0x5000cca2...

Экспансия шла 31 час при фоновой нагрузке, скорость болталась около 75 МБ/с. Пул всё время онлайн, Jellyfin и ночные бэкапы не останавливал.

Грабли №1: свободное место после расширения показывается странно — zfs list считает по старому соотношению чётности, и обещанные «на глаз» ~7 ТиБ превратились в ~6.3.
Грабли №2: старые данные так и лежат со страйпами от 4-дискового лейаута, выигрыш по месту получаешь только на новых записях. Лечится только перезаписью данных.

Итого: работает, но менее магически, чем было в анонсах OpenZFS 2.3. Знал бы заранее про пункт 2 — всё равно бы делал.

[tomcruz]

А чем старое перезаписывал? send/receive внутри пула или тупо mv туда-обратно по каталогам? Слышал, в свежем OpenZFS появилась команда zfs rewrite ровно под этот случай — в SCALE она уже доехала или ждём?

[roero]

В 25.04 ещё нет, приедет со следующим релизом, который на OpenZFS 2.4. Пока народ гоняет питоновский скрипт ребалансировки с гитхаба — по сути аккуратный cp+rm с проверкой чексумм и сохранением атрибутов. Я таким перегнал 12 ТиБ за выходные. Важно: снапшоты перед этим прибейте, иначе место не освободится, а удвоится — старые блоки останутся прибиты снапшотами.

[Rhemix]

@nyrob, Поздравляю, но позанудствую: RAIDZ1 на восьмитерабайтниках в 2026-м — это смело. Resilver на заполненном пуле — сутки, и всё это время второй отказ означает прощание с пулом целиком. Плюс статистика по URE такая, что на 5×8 ТБ вероятность споткнуться об нечитаемый сектор прямо во время ребилда уже отнюдь не нулевая, а диски у тебя с барахолки и явно из одной партии.

Я бы при апгрейде не пятый диск докидывал, а собирал RAIDZ2 из шести. И классика: RAID — не бэкап, надеюсь, реплика куда-то едет.

[krayzie]

@roero, Спасибо за отчёт, у самого 4×8 забиты в притык, ровно тот же сценарий. Один вопрос: scrub после экспансии сколько шёл и чексумм-ошибки не повылазили? На барахольных дисках это самое интересное место.

[alansmit]

@roero, Scrub запустил сразу после экспансии — 14 часов, ноль ошибок. Но тут важна приёмка: перед вводом в пул каждый диск гонял badblocks в 4 прохода (на 8 ТБ это почти трое суток, запасайтесь терпением) и смотрел SMART — атрибуты 5, 197 и 198 строго по нулям, наработка у моих была 25-30 тыс часов. Б/у диски — лотерея, но с нормальной приёмкой вполне рабочая. Реплика критичного, отвечая выше, едет ночами на VPS через restic, медиатека — на совести торрентов.

[archenjoyer]

Резонно, но давай честно про домашний контекст: у ТС там медиатека и бэкапы. Потеря пула = пересобрать библиотеку Jellyfin, неприятно, но не трагедия. А держать ради этого +2 диска по 14 тысяч и кормить их электричеством (диск ~7 Вт, при 6 ₽/кВт·ч пара дисков — это ещё ~700 ₽ в год, мелочь, но в копилку) — каждый решает по своей паранойе. Критичные документы и фото наверняка и так реплицируются отдельно, иначе проблема не в RAIDZ1.