И так порядок действий по документации:
# zfs list rpool/swap NAME USED AVAIL REFER MOUNTPOINT rpool/swap 2.066G 122G 16K - # swap -d /dev/zvol/dsk/rpool/swap # zfs set volsize=96G rpool/swap # swap -a /dev/zvol/dsk/rpool/swap # zfs list rpool/swap NAME USED AVAIL REFER MOUNTPOINT rpool/swap 2.066G 122G 16K -
Что такое? Размер тома не изменился? На самом деле ситуацию поясняет вывод следующей команды:
# zfs get all rpool/swap NAME PROPERTY VALUE SOURCE rpool/swap type volume - rpool/swap creation Thu Sep 23 16:44 2010 - rpool/swap used 2.06G - rpool/swap available 122G - rpool/swap referenced 16K - rpool/swap compressratio 1.00x - rpool/swap reservation none default rpool/swap volsize 96G local rpool/swap volblocksize 8K - rpool/swap checksum on default rpool/swap compression off default rpool/swap readonly off default rpool/swap shareiscsi off default rpool/swap copies 1 default rpool/swap refreservation 2.06G local rpool/swap primarycache all default rpool/swap secondarycache all default rpool/swap usedbysnapshots 0 - rpool/swap usedbydataset 16K - rpool/swap usedbychildren 0 - rpool/swap usedbyrefreservation 2.06G - rpool/swap logbias latency defaultНе изменился размер резервируемого пространства refreservation. Таким образом том стал разреженым, т.е. его размер будет увеличиваться по мере необходимости.
На практике это может привести к тому, что логический размер тома превысит доступное дисковое пространство. При переполнении пула это может привести к потере данных или даже краху файловой системы - не экспериментировал. Чтобы предотвратить эту ситуацию следует синхронизировать резервируемое место новому разделу тома.
# zfs set refreservation=96G rpool/swap # zfs list rpool/swap NAME USED AVAIL REFER MOUNTPOINT rpool/swap 96G 122G 16K -Таким образом мы жестко закрепили необходимое место за нашим блочным устройством. Странно что это не указано в оффициальной документации в разделе изменения размера файла подкачки...
Комментариев нет:
Отправить комментарий