https://ns.opennet.ru/openforum/vsluhforumID3/117127.html Внезапное открытие - прекрасная ZFS в прекрасной Ubuntu LTS имеет некоторые проблемы с банальным увеличением vdev. <br><br>Если у вас жила-была (такая) система с zfs'ом, тихонько подползала к пресловутым 80% заполнения, и вы решили добавить ей места, памятуя о легкости необычайной и безопасности выполнения в ней таких вещей, вас ждет малоприятный сюрприз.<br><br>Добавляем ценный ресурс к LUN, хранилище рапортует ок, радостно видим что ядро линукса подхватило новую информацию (у меня это произошло даже без необходимости дергать вручную /sys/гдетамоно/sdчтото/гдетотамеще/rescan) и... и.... и ничего.<br><br>Если это случилось: <br><br> zpool set autoexpand=on &lt;pool&gt;<br> zpool online -e &lt;pool&gt; &lt;sd?&gt;<br><br>Эта команда не принесёт успеха, но поменяет gpt метку - что вы должны <br>увидеть, запустив fdisk до и после - если этого не происходит, ядро у вас не увидело увеличения устройства, запустите rescan ещё раз.<br><br>Теперь у нас хотя бы физический диск действительно занимает весь нововыделенный объем.<br><br> reboot # без него ничего не https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#19 Sat, 17 Aug 2019 12:06:13 GMT На кластере из трёхдюймовых дискет от Verbatim<br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#18 Sat, 10 Aug 2019 15:00:15 GMT на cp/m<br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#17 Sat, 03 Aug 2019 18:59:35 GMT на дискетах 5.25"<br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#16 Wed, 31 Jul 2019 17:03:31 GMT И все это на ntfs в hyper-v Free)) <br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#15 Sat, 04 May 2019 19:24:23 GMT поверх btrfs<br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#14 Thu, 02 May 2019 04:49:54 GMT Везде есть свои "тонкости"...<br>А вот совет разместить ZFS поверх LVM - ваще огонь!<br>Круче, наверное, только замутить всё это в контейнере TrueCrypt...<br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#13 Tue, 30 Apr 2019 13:10:00 GMT &gt; * В случае с SAN не менее интересный сюрприз предоставляет multipath. Если <br>&gt; zpool по каким-то причинам будет вгружен до сборки оного.<br><br>все нормально - модные-современные системы инитят его из кэш-файла, а не сканированием устройств (это два разных юнита и второй вообще невозможно вызвать пока не отвалится первый).<br>Поэтому все просто виснет нахрен, и ждет пока руками соберешь - проверено, причем, заметьте уровень современных технологий - независимо от используемой fs ;-)<br><br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#12 Mon, 29 Apr 2019 13:52:42 GMT Оп&#8230; А смещение на LVM чем отличается от оного на GPT&#124;MBR?<br>Года так с 2012 &#8212; ничем, по моим данным. (Кроме возможности выставить offset руками, как и для zpool, когда известно какой. А какой он кстати для поданной из SAN LUN?)<br>Но с метаданныи &#8212; таки да. И еще с кэшами совсем непонятно что (я не разбирался пока).<br><br>* В случае с SAN не менее интересный сюрприз предоставляет multipath. Если zpool по каким-то причинам будет вгружен до сборки оного.<br> https://ns.opennet.ru/openforum/vsluhforumID3/117127.html#10 Wed, 17 Apr 2019 20:01:17 GMT &gt; Есть не очень красивый вариант обхода проблемы - создать пул поверх lvm. <br><br>когда уже не ресайзнулось - уже как-то и не на чем создавать lvm.<br>К тому же эффективность работы такого бутерброда будет чудовищно низкой - вы ни в жизнь не попадете размером блока zfs в размер блока lvm так, чтобы еще и смещения их совпали, контроль метаданных будет либо двойной либо бесполезный и т д.<br><br>(а при включенном сжатии zfs еще и начинает писать блоками разных размеров, что для lvm будет полным нежданчиком)<br><br>если хочется работать с lvm - просто используем xfs, ну или ext4 на крайняк - у тех все ресайзится без проблем - скучный устаревший хлам, никакой, панимаешь, интриги ;-) А все что они не умеют, сделает за них lvm.<br>