The OpenNET Project / Index page

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

Обход проблем при расширении хранилища ZFS в Linux
Внезапное открытие - прекрасная 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, где автор
"двадцать раз поперезагружался, подергал какие-то команды, хистори лог в
терминале сохранил"...но постеснялся его выложить. К счастью, я не настолько
стеснителен, и к тому же проверял результат. Надеюсь, кому-то следующему
повезет не потерять на это лишних полчаса.
 
12.04.2019 , Автор: пох
Ключи: zfs, resize, linux, zol / Лицензия: CC-BY
Раздел:    Корень / Администратору / Система / Диски и файлы / Файловые системы

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 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...
     
     
  • 2.15, Аноним (15), 22:24, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    поверх btrfs
     
     
  • 3.17, RNZ (ok), 21:59, 03/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    на дискетах 5.25"
     
     
  • 4.18, urandon (?), 18:00, 10/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    на cp/m
     

  • 1.16, ОЛЕГ (?), 20:03, 31/07/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И все это на ntfs в hyper-v Free))
     
     
  • 2.19, Аноним (19), 15:06, 17/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На кластере из трёхдюймовых дискет от Verbatim
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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