Внезапное открытие - прекрасная ZFS в прекрасной Ubuntu LTS имеет некоторые проблемы с банальным увеличением vdev.Если у вас жила-была (такая) система с zfs'ом, тихонько подползала к пресловутым 80% заполнения, и вы решили добавить ей места, памятуя о легкости необычайной и безопасности выполнения в ней таких вещей, вас ждет малоприятный сюрприз.
Добавляем ценный ресурс к LUN, хранилище рапортует ок, радостно видим что ядро линукса подхватило новую информацию (у меня это произошло даже без необходимости дергать вручную /sys/гдетамоно/sdчтото/гдетотамеще/rescan) и... и.... и ничего.
Если это случилось:
zpool set autoexpand=on <pool>
zpool online -e <pool> <sd?>Эта команда не принесёт успеха, но поменяет gpt метку - что вы должны
увидеть, запустив fdisk до и после - если этого не происходит, ядро у вас не увидело увеличения устройства, запустите rescan ещё раз.Теперь у нас хотя бы физический диск действительно занимает весь нововыделенный объем.
reboot # без него ничего не получится
Нет, все ещё счастья не воспоследовало, но!
zpool list
Показывает нечто, отличное от прочерка в графе EXPANDSZ! Победа.
Btw, наличие этой графы в выводе zpool как раз признак версии, где проблема еще/уже не исправленаzpool online -e <pool> <sd?> # еще раз!
Теперь list должен показать, что счастье настало, а zfs list - соответственно, что приросли и сами fs на этом пуле
Не правда ли, сущая ерунда по сравнению со сложнейшей командой resize2fs ?!
Долгое гугление приводит к обнаружению треда 2016(!) года о том как разработчики в очередной раз сами себе наступили на ногу, открыв устройство с O_EXCL и не сумев параллельно в нем покопаться из другого процесса, но не извольте беспокоиться, все уже переписали и закоммитил лично Бехлендорф (гуглите, в короткой статье нет места описанию этих ужасов - а то что там поназакоммичено ужас кромешный и есть) - но то ли не в ту версию что у ubuntu 18.04, то ли недостаточно хорошо закоммичено.Еще более тщательное гугление приводит к паре статей на stack, где автор "двадцать раз поперезагружался, подергал какие-то команды, хистори лог в терминале сохранил"...но постеснялся его выложить. К счастью, я не настолько стеснителен, и к тому же проверял результат. Надеюсь, кому-то следующему повезет не потерять на это лишних полчаса.
URL:
Обсуждается: https://www.opennet.ru/tips/info/3104.shtml
Где бы почитать как уменьшать ZFS без тупого переноса данных с последующим пересозданием с меньшим размером
эмм... то есть вот эти прекрасные грабли не навели вас на мысли что их лучше и расширять-то не пытаться бы? ;-)вкратце - никак, такой функционал вообще не предусмотрен в open zfs (в оракловой, по слухам, был в каких-то последних патчах, но я боюсь там свежего не меньше чем в бес...свободной версии)
хотите увеличить пул - просто добавьте еще один vdev, не расширяйте старый (если мы о хранилке, где диски виртуальные и без разницы, один увеличить или второй налить). При необходимости его можно будет потом удалить из пула без потери данных, эта фича с недавних пор - поддерживается (_не_ для рейда!).
А поскольку тут ничего не надо ресайзить на ходу и перезаписывать метки, то даже линукс справится.
то есть насоздавать кучу разделов и ими уже оперировать добавляя в пул или удаляя из него ?
э... но зачем?Статья о ситуации, когда "диск" целиком виртуален, раздается с ентерпрайзной хранилки, которой что пнем о сову, что совой об пень - может увеличить существующий lun, может десяток новых насыпать.
Поскольку как-то глупо плодить виртуальные диски с одной и той же хранилки - разумеется, напрашивающийся вариант - долить гигабайтов в существующий, а в нем, на ровном месте, оказалась засада - больше я так делать не буду.Никаких разделов при этом не создается (кроме фейковой gpt метки, которую ZoL сама создает, и сама меняет если захотелось).
Если диск у тебя физический - то новый диск это просто новый vdev. Разделов на нем создавать не надо, линуксная сама тебе создаст, bsd'шным от них только вред.
Но на физических дисках обычно если уж связываются с zfs, создают зеркало или raid, а там открытий чудных может оказаться гораздо больше.
Правильный вариант добавлять место в физический пул - просто делать zpool add tank mirror sde sdd
(zfs совершенно все равно, из чего до этого был собран tank - оно где было, там и останется). Но если старые диски хочется при этом потихоньку выкинуть, и ты планируешь заменять их по одному на диски большего объема - то, на мой взгляд, при нынешней надежности всей конструкции, лучше этого не делать, воспользовавшись send. Попутно старый массив послужит сам себе бэкапом.
Простите, а зачем вы используете GPT разделы под ZFS, если тома все равно отдаете с СХД? Отдавайте в пул блочное устройство целиком и пропустите как раз те шаги которые мешают растянуть пул. Растягивая блочный девайс, вы не растягиваете GPT раздел на нем и это мешает ZFS увидить что ей "привалило" места. Вероятно из-за этого и все прыжки?p.s. под BSD и geom все расширяется без проблем. Похоже это все же ZoL-specific
> Простите, а зачем вы используете GPT разделы под ZFSтак работает ZoL
(на практике это просто метка, упрощающая ей поиск пула при скане, и попутно резервирующая хвост на случай внезапной необходимости что-то записать в последние сектора - например, метки md multipath)> пропустите как раз те шаги которые мешают растянуть пул. Растягивая блочный
> девайс, вы не растягиваете GPT раздел на нем и это мешаетнаоборот, она это сделает автоматически (и в отличие от самой zfs, это у нее - получится, но вот ядро, похоже, не сможет перечитать новую таблицу, пока разделы все еще кем-то открыты на запись).
Почему и после перезагрузки нужен еще один пинок, не смотря на явное разрешение авторесайза - это вот я не понял.
Вы смешали всё в одну кучу.
zpool online -e принудительно расширяет пул и работает в линуксе давно и как положено:
# fallocate -l 1G file0
# zpool create test `pwd`/file0
# zpool list test
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
test 1008M 106K 1008M - 0% 0% 1.00x ONLINE -
# zpool get autoexpand test
NAME PROPERTY VALUE SOURCE
test autoexpand off default
# cat file0 >> file0
# zpool online -e test `pwd`/file0
# zpool list test
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
test 1.98G 141K 1.98G - 0% 0% 1.00x ONLINE -С autoexpand связи никакой.
Ваша проблема, как вам правильно сказали - в необновленном gpt label.
Если мне не изменяет склероз, обойтись без ребута можно при помощи partprobe:
partprobe - inform the OS of partition table changes# partprobe
Warning: Not all of the space available to /dev/vdb appears to be used,
you can fix the GPT to use all of the space (an extra 10485760 blocks) or
continue with the current setting?# zpool online -e test /dev/vdb
Что касается autoexpand, то вся история тут:
https://github.com/zfsonlinux/zfs/issues/120
Есть не очень красивый вариант обхода проблемы - создать пул поверх lvm. Тогда, при расширении lvm, zfs ресайзится онлайн без ребутов.
> Есть не очень красивый вариант обхода проблемы - создать пул поверх lvm.когда уже не ресайзнулось - уже как-то и не на чем создавать lvm.
К тому же эффективность работы такого бутерброда будет чудовищно низкой - вы ни в жизнь не попадете размером блока zfs в размер блока lvm так, чтобы еще и смещения их совпали, контроль метаданных будет либо двойной либо бесполезный и т д.(а при включенном сжатии zfs еще и начинает писать блоками разных размеров, что для lvm будет полным нежданчиком)
если хочется работать с lvm - просто используем xfs, ну или ext4 на крайняк - у тех все ресайзится без проблем - скучный устаревший хлам, никакой, панимаешь, интриги ;-) А все что они не умеют, сделает за них lvm.
Оп… А смещение на LVM чем отличается от оного на GPT|MBR?
Года так с 2012 — ничем, по моим данным. (Кроме возможности выставить offset руками, как и для zpool, когда известно какой. А какой он кстати для поданной из SAN LUN?)
Но с метаданныи — таки да. И еще с кэшами совсем непонятно что (я не разбирался пока).* В случае с SAN не менее интересный сюрприз предоставляет multipath. Если zpool по каким-то причинам будет вгружен до сборки оного.
> * В случае с SAN не менее интересный сюрприз предоставляет multipath. Если
> zpool по каким-то причинам будет вгружен до сборки оного.все нормально - модные-современные системы инитят его из кэш-файла, а не сканированием устройств (это два разных юнита и второй вообще невозможно вызвать пока не отвалится первый).
Поэтому все просто виснет нахрен, и ждет пока руками соберешь - проверено, причем, заметьте уровень современных технологий - независимо от используемой fs ;-)
Везде есть свои "тонкости"...
А вот совет разместить ZFS поверх LVM - ваще огонь!
Круче, наверное, только замутить всё это в контейнере TrueCrypt...
поверх btrfs
на дискетах 5.25"
на cp/m
И все это на ntfs в hyper-v Free))
На кластере из трёхдюймовых дискет от Verbatim