The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

"Раздел полезных советов: Обход проблем при расширении хранил..."  +/
Сообщение от 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:
Обсуждается: https://www.opennet.ru/tips/info/3104.shtml

Ответить | Правка | Cообщить модератору

Оглавление

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


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

2. "Обход проблем при расширении хранилища ZFS в Linux"  +/
Сообщение от пох (?), 16-Апр-19, 10:21 
эмм... то есть вот эти прекрасные грабли не навели вас на мысли что их лучше и расширять-то не пытаться бы? ;-)

вкратце - никак, такой функционал вообще не предусмотрен в open zfs (в оракловой, по слухам, был в каких-то последних патчах, но я боюсь там свежего не меньше чем в бес...свободной версии)

хотите увеличить пул - просто добавьте еще один vdev, не расширяйте старый (если мы о хранилке, где диски виртуальные и без разницы, один увеличить или второй налить). При необходимости его можно будет потом удалить из пула без потери данных, эта фича с недавних пор - поддерживается (_не_ для рейда!).
А поскольку тут ничего не надо ресайзить на ходу и перезаписывать метки, то даже линукс справится.


Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Обход проблем при расширении хранилища ZFS в Linux"  +/
Сообщение от VecHemail (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ообщить модератору

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

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




Спонсоры:
MIRhosting
Fornex
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру