Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Обход проблем при расширении хранил..."	+/–
Сообщение от auto_tips (ok), 16-Апр-19, 08:51
Внезапное открытие - прекрасная 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: Обсуждается: http://www.opennet.dev/tips/info/3104.shtml
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
Сообщение от VecH (ok), 16-Апр-19, 08:51
Где бы почитать как уменьшать ZFS без тупого переноса данных с последующим пересозданием с меньшим размером
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от пох (?), 16-Апр-19, 10:21
	эмм... то есть вот эти прекрасные грабли не навели вас на мысли что их лучше и расширять-то не пытаться бы? ;-) вкратце - никак, такой функционал вообще не предусмотрен в open zfs (в оракловой, по слухам, был в каких-то последних патчах, но я боюсь там свежего не меньше чем в бес...свободной версии) хотите увеличить пул - просто добавьте еще один vdev, не расширяйте старый (если мы о хранилке, где диски виртуальные и без разницы, один увеличить или второй налить). При необходимости его можно будет потом удалить из пула без потери данных, эта фича с недавних пор - поддерживается (_не_ для рейда!). А поскольку тут ничего не надо ресайзить на ходу и перезаписывать метки, то даже линукс справится.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от VecH (ok), 16-Апр-19, 10:38
	то есть насоздавать кучу разделов и ими уже оперировать добавляя в пул или удаляя из него ?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от пох (?), 16-Апр-19, 14:32
	э... но зачем? Статья о ситуации, когда "диск" целиком виртуален, раздается с ентерпрайзной хранилки, которой что пнем о сову, что совой об пень - может увеличить существующий lun, может десяток новых насыпать. Поскольку как-то глупо плодить виртуальные диски с одной и той же хранилки - разумеется, напрашивающийся вариант - долить гигабайтов в существующий, а в нем, на ровном месте, оказалась засада - больше я так делать не буду. Никаких разделов при этом не создается (кроме фейковой gpt метки, которую ZoL сама создает, и сама меняет если захотелось). Если диск у тебя физический - то новый диск это просто новый vdev. Разделов на нем создавать не надо, линуксная сама тебе создаст, bsd'шным от них только вред. Но на физических дисках обычно если уж связываются с zfs, создают зеркало или raid, а там открытий чудных может оказаться гораздо больше. Правильный вариант добавлять место в физический пул - просто делать zpool add tank mirror sde sdd (zfs совершенно все равно, из чего до этого был собран tank - оно где было, там и останется). Но если старые диски хочется при этом потихоньку выкинуть, и ты планируешь заменять их по одному на диски большего объема - то, на мой взгляд, при нынешней надежности всей конструкции, лучше этого не делать, воспользовавшись send. Попутно старый массив послужит сам себе бэкапом.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
Сообщение от Vortigont (?), 16-Апр-19, 12:21
Простите, а зачем вы используете GPT разделы под ZFS, если тома все равно отдаете с СХД? Отдавайте в пул блочное устройство целиком и пропустите как раз те шаги которые мешают растянуть пул. Растягивая блочный девайс, вы не растягиваете GPT раздел на нем и это мешает ZFS увидить что ей "привалило" места. Вероятно из-за этого и все прыжки? p.s. под BSD и geom все расширяется без проблем. Похоже это все же ZoL-specific
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от пох (?), 16-Апр-19, 14:37
	> Простите, а зачем вы используете GPT разделы под ZFS так работает ZoL (на практике это просто метка, упрощающая ей поиск пула при скане, и попутно резервирующая хвост на случай внезапной необходимости что-то записать в последние сектора - например, метки md multipath) > пропустите как раз те шаги которые мешают растянуть пул. Растягивая блочный > девайс, вы не растягиваете GPT раздел на нем и это мешает наоборот, она это сделает автоматически (и в отличие от самой zfs, это у нее - получится, но вот ядро, похоже, не сможет перечитать новую таблицу, пока разделы все еще кем-то открыты на запись). Почему и после перезагрузки нужен еще один пинок, не смотря на явное разрешение авторесайза - это вот я не понял.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "Обход проблем при расширении хранилища ZFS в Linux"	+1 +/–
	Сообщение от yur (??), 17-Апр-19, 15:08
	Вы смешали всё в одну кучу. 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
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
Сообщение от A.D. (?), 17-Апр-19, 07:33
Есть не очень красивый вариант обхода проблемы - создать пул поверх lvm. Тогда, при расширении lvm, zfs ресайзится онлайн без ребутов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от пох (?), 17-Апр-19, 23:01
	> Есть не очень красивый вариант обхода проблемы - создать пул поверх lvm. когда уже не ресайзнулось - уже как-то и не на чем создавать lvm. К тому же эффективность работы такого бутерброда будет чудовищно низкой - вы ни в жизнь не попадете размером блока zfs в размер блока lvm так, чтобы еще и смещения их совпали, контроль метаданных будет либо двойной либо бесполезный и т д. (а при включенном сжатии zfs еще и начинает писать блоками разных размеров, что для lvm будет полным нежданчиком) если хочется работать с lvm - просто используем xfs, ну или ext4 на крайняк - у тех все ресайзится без проблем - скучный устаревший хлам, никакой, панимаешь, интриги ;-) А все что они не умеют, сделает за них lvm.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от PnDx (ok), 29-Апр-19, 16:52
	Оп… А смещение на LVM чем отличается от оного на GPT|MBR? Года так с 2012 — ничем, по моим данным. (Кроме возможности выставить offset руками, как и для zpool, когда известно какой. А какой он кстати для поданной из SAN LUN?) Но с метаданныи — таки да. И еще с кэшами совсем непонятно что (я не разбирался пока). * В случае с SAN не менее интересный сюрприз предоставляет multipath. Если zpool по каким-то причинам будет вгружен до сборки оного.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	13. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от пох (?), 30-Апр-19, 16:10
	> * В случае с SAN не менее интересный сюрприз предоставляет multipath. Если > zpool по каким-то причинам будет вгружен до сборки оного. все нормально - модные-современные системы инитят его из кэш-файла, а не сканированием устройств (это два разных юнита и второй вообще невозможно вызвать пока не отвалится первый). Поэтому все просто виснет нахрен, и ждет пока руками соберешь - проверено, причем, заметьте уровень современных технологий - независимо от используемой fs ;-)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
Сообщение от iCat (ok), 02-Май-19, 07:49
Везде есть свои "тонкости"... А вот совет разместить ZFS поверх LVM - ваще огонь! Круче, наверное, только замутить всё это в контейнере TrueCrypt...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от Аноним (15), 04-Май-19, 22:24
	поверх btrfs
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от RNZ (ok), 03-Авг-19, 21:59
	на дискетах 5.25"
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	18. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от urandon (?), 10-Авг-19, 18:00
	на cp/m
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

16. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
Сообщение от ОЛЕГ (?), 31-Июл-19, 20:03
И все это на ntfs в hyper-v Free))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Обход проблем при расширении хранилища ZFS в Linux"	+/–
	Сообщение от Аноним (19), 17-Авг-19, 15:06
	На кластере из трёхдюймовых дискет от Verbatim
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема