Сперва смотрим название и размер “диска”:

zfs list

Диски, созданные во FreeNAS для экспорта по iSCSI, не имеют точки монтирования.
Именуются они по схеме pool_name/volume_name
Следующий столбец (USED) нам покажет его текущий размер.
Изменить размер вольюма (без ошибок может быть изменение только в сторону увеличения) можно командой

zfs set volsize=7.08T pool_name/volume_name

Крайне рекомендуется менять размер вольюма только после отключения istgtd
Узнать размер вольюма в байтах можно командой

zfs get -Hp volsize pool_name/volume_name

Эти данные могут пригодиться на стороне инициатора (хоста iscsi)
Узнать это же значение в секторах можно, поделив размер в байтах на 512

If zpool had been located on dynamically expanded RAID arrays with GPT partitions, when RAID volume size had been increased, we need to reconfigure GPT first, and formatting to ZFS newly added partition piece.

We can start it by using gpart utility

example:

We have added new HDD to LSI2208-based RAID-5 array, used with FreeNAS

The RAID'ed volume is /dev/mfid0, and it have two partitions:

#gpart show mfid0
        34    19521474493    mfid0    GPT (10T) [CORRUPT]
        34             94             - free - (47k)
       128       16777216        1    freebsd-swap (8.0G)
  16777344    19504697183        2    freebsd-zfs  (9.1T)

After expanding RAID, we've got corrupted GPT table, and we need to repair it with gpart recover command

gpart recover mfid0
mfid0 recovered

Now we can see an unallocated disk space.

gpart show mfid0
         34    23425769405    mfid0    GPT (10T)
         34             94             - free - (47k)
        128       16777216        1    freebsd-swap (8.0G)
   16777344    19504697183        2    freebsd-zfs  (9.1T)
19521474527     3904294912             - free - (1.8T)

We can try to resize partition, but, due it is used by Zpool, our tryout can be unsuccessful.

gpart resize -i 2 mfid0
device busy

The safest way - is to export ZFS pool for it's import after partition changing.

zpool export -f SAN-1
gpart resize -i 2 mfid0
zpool import SAN-1

Если у нас пул из нескольких диков, то не надо экспортировать пул, а по одному отключать диски и увеличивать им размер

zpool offline -f SAN-1 UUID-0001-mfid0
gpart resize -i 2 mfid0
...

But, unfortunately, I still can not use all volume size, even zpool autoresize is ON. I need to manually initialize all new space for ZFS.

Если мы не экспортировали целиковый пул, а просто отключали диск в оффлайн, то теперь надо отключенный ранее диск подключить, после чего повторять процедуру отключения – изменения размера – подключения по очереди для всех оставшихся дисков

It can be done by using zpool online -e command. First, we need to know an UUID of our ZFS-containing partition (mfid0p2 in our case)

#zpool status SAN-1

Thus, we get gptid/uuid of device mfid0p2, and, for example, gptid/uuid-devi-ce00-mfid0p2 was given. Now we can add our rest volume's space to zpool by initializing it:

zpool online -e SAN-1 gptid/uuid-devi-ce00-mfid0p2

Done!

Описанная выше технология годится, если нас не слшком волнует, что пространство на лоических дисках, входящих в пул, будет заполнено “полосами”.

Полосатость годится для домашней файлопомойки, но никак не для продакшн стораджа. В продакшне диски надо не просто подкючать обратно, но и переформатировать и проводить resilver, что позволяет команда

zpool replace [-f] <pool> <volume>

Пробуем провести операцию в лоб:

zpool status
  pool: RAID
 state: ONLINE
  scan: scrub repaired 0 in 20h13m with 0 errors on Tue Oct  7 10:11:01 2014
config:
    NAME                                            STATE     READ WRITE CKSUM
    RAID                                            ONLINE       0     0     0
      raidz1-0                                      ONLINE       0     0     0
	gptid/c79b855d-0930-11e4-99de-001517ca7a10  ONLINE       0     0     0
	gptid/ea917197-45be-11e4-9171-001517ca7a10  ONLINE       0     0     0
	gptid/cad33bd5-0930-11e4-99de-001517ca7a10  ONLINE       0     0     0
errors: No known data errors

Отключем диск da2p2 (его uuid мы видим в строке после gptid/, а определить соответствие помогает команда

gpart list da2

Она нам в строке rawuuid покажет gpt имя вольюма. Итак, отключаем:

zpool offline RAID gptid/cad33bd5-0930-11e4-99de-001517ca7a10

Проверяем:

zpool status
  pool: RAID
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using 'zpool online' or replace the device with
	'zpool replace'.
  scan: scrub repaired 0 in 20h13m with 0 errors on Tue Oct  7 10:11:01 2014
config:
    NAME                                            STATE     READ WRITE CKSUM
    RAID                                            DEGRADED     0     0     0
      raidz1-0                                      DEGRADED     0     0     0
	gptid/c79b855d-0930-11e4-99de-001517ca7a10  ONLINE       0     0     0
	gptid/ea917197-45be-11e4-9171-001517ca7a10  ONLINE       0     0     0
	2433944954983788812                         OFFLINE      0     0     0  was gptid/cad33bd5-0930-11e4-99de-001517ca7a10

errors: No known data errors

Итак, начало нормальное. Увеличиваем размер партиции с 10 до 13 ТБ:

gpart resize -i 2 da2

Вольюм занимает весь доступный вниз объем. Если мы сделаем

zpool online -e gptid/cad33bd5-0930-11e4-99de-001517ca7a10

то оно встанет назад с новым объемом, но с “полосатой” структурой данных, чего нам хоелось бы избежать.

Если мы попроубем заменить диск на самого себя “в лоб” (чтобы оно сделало resilver и устранило “полосатость” данных

zpool replace RAID 2433944954983788812 gptid/cad33bd5-0930-11e4-99de-001517ca7a10

то оно нас пошлет со словами:

invalid vdev specification
use '-f' to override the following errors:
/dev/gptid/cad33bd5-0930-11e4-99de-001517ca7a10 is part of active pool 'RAID'

Хорошо: скажем ему с параметром -f. Даже предположим, что информация об uuid этого раздела записана где-то еще (а это так), и, чтобы не было путаницы, убъём имеющийся раздел и создадим новый:

gpart delete -i 2 da2
> da2p2 deleted
gpart add -t freebsd-zfs da2
> da2p2 added

Найдем uuid новой партиции:

gpart list da2 | grep -a7 da2p2 | grep rawuuid

Оно нам ответит:

rawuuid: 63227ac7-4e0c-11e4-9c46-001517ca7a10

Это новый вольюм, на который будем менять. Пробуем:

zpool replace -f RAID 2433944954983788812 gptid/63227ac7-4e0c-11e4-9c46-001517ca7a10
invalid vdev specification
the following errors must be manually repaired:
/dev/gptid/63227ac7-4e0c-11e4-9c46-001517ca7a10 is part of active pool 'RAID'

Жестокий облом. Оказывается, надо потереть начало и конец вольюма, где есть инфа о членстве вольюма в пуле RAID.

До попытки выполнить zpool replace, данный вольюм (партиция) уже был ранее загнан в пул с опцией -e, значит инфа о “членстве” в пуле находится где-то га диске.

Инструкция к ZFS говорит, что инфа о членстве раздела в ZFS размещается в начальной и в оконечной частях партиции.

Данные о начальном секторе партиции (вольюма) и о конечном секторе проще всего вытащить командой

gpart show da2
=>         34  29301800893  da2  GPT  (13T)
           34           94       - free -  (47k)
          128     16777216    1  freebsd-swap  (8.0G)
     16777344  29285023583    2  freebsd-zfs  (13T)

Начало партиции (первые 5,12 MB) затереть проще всего командой

dd if=/dev/zero of=/dev/da2p2 bs=512 count=10240

Однако, замена опять не пройдет, оно будет ругаться, как и прежде. И ругаться оно будет до тех пор, пока команда

zdb -l /dev/gptid/63227ac7-4e0c-11e4-9c46-001517ca7a10

не даст нам информацию о том, что следов о членстве в zfs пуле на диске не обнаружено.

Поможет опять же dd, но с опцией oseek=, где указан сектор, с которого начнем писать нули.

Это мы легко можем взять из вывода команты gpart show da2 в части, относящейся к партиции da2p2: там указан ее размер в секторах, так что мы тупо вычитаем из размера партиции то количество секторов, которое будем писать, и получаем искомые значения.

Затирать будем для надежности и ровного счета 100 000 секторов (52 Мб). Пишем:

gpart show da2
=>         34  29301800893  da2  GPT  (13T)
           34           94       - free -  (47k)
          128     16777216    1  freebsd-swap  (8.0G)
     16777344  29285023583    2  freebsd-zfs  (13T)

Размер второй партиции (которую загоняем в zfs пул) указан в последней строке, второй столбец.

Мы пишем туда 100 000 секторов, и нам надо вычислить сектор, с которого надо начинать запись нулей.

Считаем: 29285023583 - 100000 = 29284923583.

Пишем:

dd if=/dev/zero of=/dev/da2p2 bs=512 count=100000 oseek=29284923583
100000+0 records in
100000+0 records out
51200000 bytes transferred in 1.942254 secs (26361127 bytes/sec)

Проверяем, пройдет ли импорт:

zdb -l /dev/gptid/63227ac7-4e0c-11e4-9c46-001517ca7a10
--------------------------------------------
LABEL 0
--------------------------------------------
failed to unpack label 0
--------------------------------------------
LABEL 1
--------------------------------------------
failed to unpack label 1
--------------------------------------------
LABEL 2
--------------------------------------------
failed to unpack label 2
--------------------------------------------
LABEL 3
--------------------------------------------
failed to unpack label 3

Теперь можно со спокойной душой делать zpool replace

zpool replace RAID 2433944954983788812 gptid/63227ac7-4e0c-11e4-9c46-001517ca7a10

Поверяемся:

zpool status
  pool: RAID
 state: DEGRADED
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 Tue Oct  7 14:52:02 2014
        64.1M scanned out of 30.2T at 2.79M/s, (scan is slow, no estimated time)
        20.6M resilvered, 0.00% done
config:
    NAME                                              STATE     READ WRITE CKSUM
    RAID                                              DEGRADED     0     0     0
      raidz1-0                                        DEGRADED     0     0     0
	gptid/c79b855d-0930-11e4-99de-001517ca7a10    ONLINE       0     0     0
	gptid/ea917197-45be-11e4-9171-001517ca7a10    ONLINE       0     0     0
	replacing-2                                   OFFLINE      0     0     0
	  2433944954983788812                         OFFLINE      0     0     0  was gptid/cad33bd5-0930-11e4-99de-001517ca7a10
	  gptid/63227ac7-4e0c-11e4-9c46-001517ca7a10  ONLINE       0     0     0  (resilvering)
errors: No known data errors

Когда resilvering закончен, пул все еще остается в состоянии DEGRADED. Но, если ошибок нет, то это исправимо: состояние degraded вызвано наличием неподключенного диска в пуле.

Диск 2433944954983788812 у нас OFFLINE, и подключить мы его не сможем - мы его же убили при replace. Посему делаем

zpool detach RAID 2433944954983788812

Проверяемся:

zpool status
  pool: RAID
 state: ONLINE
  scan: resilvered 10.1T in 19h29m with 0 errors on Sun Oct 9 00:04:24 2014
config:

	NAME                                            STATE     READ WRITE CKSUM
	RAID                                            ONLINE       0     0     0
	  raidz1-0                                      ONLINE       0     0     0
	    gptid/c79b855d-0930-11e4-99de-001517ca7a10  ONLINE       0     0     0
	    gptid/ea917197-45be-11e4-9171-001517ca7a10  ONLINE       0     0     0
	    gptid/63227ac7-4e0c-11e4-9c46-001517ca7a10  ONLINE       0     0     0

errors: No known data errors

http://www.freebsddiary.org/zfs-resizing.php