| 1.1, VecH (ok), 08:51, 16/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Где бы почитать как уменьшать ZFS без тупого переноса данных с последующим пересозданием с меньшим размером
| | |
| |
| 2.2, пох (?), 10:21, 16/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
эмм... то есть вот эти прекрасные грабли не навели вас на мысли что их лучше и расширять-то не пытаться бы? ;-)
вкратце - никак, такой функционал вообще не предусмотрен в open zfs (в оракловой, по слухам, был в каких-то последних патчах, но я боюсь там свежего не меньше чем в бес...свободной версии)
хотите увеличить пул - просто добавьте еще один vdev, не расширяйте старый (если мы о хранилке, где диски виртуальные и без разницы, один увеличить или второй налить). При необходимости его можно будет потом удалить из пула без потери данных, эта фича с недавних пор - поддерживается (_не_ для рейда!).
А поскольку тут ничего не надо ресайзить на ходу и перезаписывать метки, то даже линукс справится.
| | |
| |
| 3.3, VecH (ok), 10:38, 16/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
то есть насоздавать кучу разделов и ими уже оперировать добавляя в пул или удаляя из него ?
| | |
| |
| 4.5, пох (?), 14:32, 16/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
э... но зачем?
Статья о ситуации, когда "диск" целиком виртуален, раздается с ентерпрайзной хранилки, которой что пнем о сову, что совой об пень - может увеличить существующий lun, может десяток новых насыпать.
Поскольку как-то глупо плодить виртуальные диски с одной и той же хранилки - разумеется, напрашивающийся вариант - долить гигабайтов в существующий, а в нем, на ровном месте, оказалась засада - больше я так делать не буду.
Никаких разделов при этом не создается (кроме фейковой gpt метки, которую ZoL сама создает, и сама меняет если захотелось).
Если диск у тебя физический - то новый диск это просто новый vdev. Разделов на нем создавать не надо, линуксная сама тебе создаст, bsd'шным от них только вред.
Но на физических дисках обычно если уж связываются с zfs, создают зеркало или raid, а там открытий чудных может оказаться гораздо больше.
Правильный вариант добавлять место в физический пул - просто делать zpool add tank mirror sde sdd
(zfs совершенно все равно, из чего до этого был собран tank - оно где было, там и останется). Но если старые диски хочется при этом потихоньку выкинуть, и ты планируешь заменять их по одному на диски большего объема - то, на мой взгляд, при нынешней надежности всей конструкции, лучше этого не делать, воспользовавшись send. Попутно старый массив послужит сам себе бэкапом.
| | |
|
|
|
| 1.4, Vortigont (?), 12:21, 16/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Простите, а зачем вы используете GPT разделы под ZFS, если тома все равно отдаете с СХД? Отдавайте в пул блочное устройство целиком и пропустите как раз те шаги которые мешают растянуть пул. Растягивая блочный девайс, вы не растягиваете GPT раздел на нем и это мешает ZFS увидить что ей "привалило" места. Вероятно из-за этого и все прыжки?
p.s. под BSD и geom все расширяется без проблем. Похоже это все же ZoL-specific
| | |
| |
| 2.6, пох (?), 14:37, 16/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Простите, а зачем вы используете GPT разделы под ZFS
так работает ZoL
(на практике это просто метка, упрощающая ей поиск пула при скане, и попутно резервирующая хвост на случай внезапной необходимости что-то записать в последние сектора - например, метки md multipath)
> пропустите как раз те шаги которые мешают растянуть пул. Растягивая блочный
> девайс, вы не растягиваете GPT раздел на нем и это мешает
наоборот, она это сделает автоматически (и в отличие от самой zfs, это у нее - получится, но вот ядро, похоже, не сможет перечитать новую таблицу, пока разделы все еще кем-то открыты на запись).
Почему и после перезагрузки нужен еще один пинок, не смотря на явное разрешение авторесайза - это вот я не понял.
| | |
| |
| 3.8, yur (??), 15:08, 17/04/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вы смешали всё в одну кучу.
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
| | |
|
|
| 1.7, A.D. (?), 07:33, 17/04/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Есть не очень красивый вариант обхода проблемы - создать пул поверх lvm. Тогда, при расширении lvm, zfs ресайзится онлайн без ребутов.
| | |
| |
| 2.10, пох (?), 23:01, 17/04/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Есть не очень красивый вариант обхода проблемы - создать пул поверх lvm.
когда уже не ресайзнулось - уже как-то и не на чем создавать lvm.
К тому же эффективность работы такого бутерброда будет чудовищно низкой - вы ни в жизнь не попадете размером блока zfs в размер блока lvm так, чтобы еще и смещения их совпали, контроль метаданных будет либо двойной либо бесполезный и т д.
(а при включенном сжатии zfs еще и начинает писать блоками разных размеров, что для lvm будет полным нежданчиком)
если хочется работать с lvm - просто используем xfs, ну или ext4 на крайняк - у тех все ресайзится без проблем - скучный устаревший хлам, никакой, панимаешь, интриги ;-) А все что они не умеют, сделает за них lvm.
| | |
| |
| 3.12, PnDx (ok), 16:52, 29/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Оп… А смещение на LVM чем отличается от оного на GPT|MBR?
Года так с 2012 — ничем, по моим данным. (Кроме возможности выставить offset руками, как и для zpool, когда известно какой. А какой он кстати для поданной из SAN LUN?)
Но с метаданныи — таки да. И еще с кэшами совсем непонятно что (я не разбирался пока).
* В случае с SAN не менее интересный сюрприз предоставляет multipath. Если zpool по каким-то причинам будет вгружен до сборки оного.
| | |
| |
| 4.13, пох (?), 16:10, 30/04/2019 [^] [^^] [^^^] [ответить]
| +/– |
> * В случае с SAN не менее интересный сюрприз предоставляет multipath. Если
> zpool по каким-то причинам будет вгружен до сборки оного.
все нормально - модные-современные системы инитят его из кэш-файла, а не сканированием устройств (это два разных юнита и второй вообще невозможно вызвать пока не отвалится первый).
Поэтому все просто виснет нахрен, и ждет пока руками соберешь - проверено, причем, заметьте уровень современных технологий - независимо от используемой fs ;-)
| | |
|
|
|
| 1.14, iCat (ok), 07:49, 02/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Везде есть свои "тонкости"...
А вот совет разместить ZFS поверх LVM - ваще огонь!
Круче, наверное, только замутить всё это в контейнере TrueCrypt...
| | |
|