39567 2021-01-19 18:55:54 +0300 В инсталяторе не работает форматирование в xfs 2021-08-10 11:08:44 +0300 1 1 4 Development Sisyphus libevms unstable all Linux CLOSED FIXED P5 normal --- 33000 40561 1 antohami mcpain aen boyarsh klark mcpain mike rider qa-sisyphus oldest_to_newest 195537 0 antohami 2021-01-19 18:55:54 +0300 В инсталяторе не работает форматирование в xfs. Проблема началась после обновления xfsprogs до версии 5.9.0-alt1. 199059 1 antohami 2021-06-09 01:09:52 +0300 Плагин для работы с файловой системой xfs находится в пакете libevms. Воспроизведение проблемы: На шаге "Подготовка диска" выбрать форматирование одного из разделов в xfs. Нажать кнопку далее. Появляется окно с критической ошибкой: операция не позволена. В /var/log/evms-engine.log: июн 09 01:01:57 localhost.localdomain _2_ Engine: is_in_use: Object sda1 is used as volume /dev/evms/sda1. июн 09 01:02:00 localhost.localdomain _5_ Engine: is_object_change_pending: Change pending: Object sda_mbr is dirty. июн 09 01:02:00 localhost.localdomain _5_ Engine: is_object_change_pending: Change pending: Object sda3 needs to be activated. июн 09 01:02:00 localhost.localdomain _5_ Engine: is_volume_change_pending: Change pending: Volume /dev/evms/sda2 needs to have the XFS file system put on it. июн 09 01:02:00 localhost.localdomain _5_ Engine: is_volume_change_pending: Change pending: Volume /dev/evms/sda3 needs to be activated. июн 09 01:02:00 localhost.localdomain _5_ Engine: is_volume_change_pending: Change pending: Volume /dev/evms/sda3 needs to have the XFS file system put on it. июн 09 01:02:02 localhost.localdomain _5_ Engine: is_object_change_pending: Change pending: Object sda_mbr is dirty. июн 09 01:02:02 localhost.localdomain _5_ Engine: is_object_change_pending: Change pending: Object sda3 needs to be activated. июн 09 01:02:02 localhost.localdomain _5_ Engine: is_volume_change_pending: Change pending: Volume /dev/evms/sda2 needs to have the XFS file system put on it. июн 09 01:02:02 localhost.localdomain _5_ Engine: is_volume_change_pending: Change pending: Volume /dev/evms/sda3 needs to be activated. июн 09 01:02:02 localhost.localdomain _5_ Engine: is_volume_change_pending: Change pending: Volume /dev/evms/sda3 needs to have the XFS file system put on it. июн 09 01:02:03 localhost.localdomain _2_ XFS: xfs_create: mkfs.xfs completed with exit code 256 200852 2 ptrnine 2021-07-23 14:37:25 +0300 mkfs.xfs не нравится log size, который EVMS хочет задать при форматировании: [root@localhost altlinux]# fdisk -l /dev/evms/sdb1 Disk /dev/evms/sdb1: 5 GiB, 5365563392 bytes, 10479616 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes [root@localhost altlinux]# mkfs.xfs -lsize=4194304 /dev/evms/sdb1 log size 1024 blocks too small, minimum size is 1986 blocks 200869 3 aen 2021-07-23 20:11:26 +0300 (Ответ для Slava Aseev на комментарий #2) > mkfs.xfs не нравится log size, который EVMS хочет задать при форматировании: > > [root@localhost altlinux]# fdisk -l /dev/evms/sdb1 > Disk /dev/evms/sdb1: 5 GiB, 5365563392 bytes, 10479616 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > [root@localhost altlinux]# mkfs.xfs -lsize=4194304 /dev/evms/sdb1 > log size 1024 blocks too small, minimum size is 1986 blocks Есть предложения? 200887 4 boyarsh 2021-07-26 10:52:53 +0300 (Ответ для AEN на комментарий #3) > (Ответ для Slava Aseev на комментарий #2) > > mkfs.xfs не нравится log size, который EVMS хочет задать при форматировании: > > > > [root@localhost altlinux]# fdisk -l /dev/evms/sdb1 > > Disk /dev/evms/sdb1: 5 GiB, 5365563392 bytes, 10479616 sectors > > Units: sectors of 1 * 512 = 512 bytes > > Sector size (logical/physical): 512 bytes / 512 bytes > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > > [root@localhost altlinux]# mkfs.xfs -lsize=4194304 /dev/evms/sdb1 > > log size 1024 blocks too small, minimum size is 1986 blocks > > Есть предложения? Надо менять ecms, какие ещё могут быть варианты? 200926 5 klark 2021-07-26 21:59:20 +0300 (In reply to Anton V. Boyarshinov from comment #4) > (Ответ для AEN на комментарий #3) > > Есть предложения? > Надо менять ecms, какие ещё могут быть варианты? Видимо имелось ввиду патчить xfs-плагин libevms? 200930 6 boyarsh 2021-07-27 11:10:23 +0300 (Ответ для Leonid Krivoshein на комментарий #5) > (In reply to Anton V. Boyarshinov from comment #4) > > (Ответ для AEN на комментарий #3) > > > Есть предложения? > > Надо менять ecms, какие ещё могут быть варианты? > Видимо имелось ввиду патчить xfs-плагин libevms? Я не имею ни малейшего представления о внутреннем устройстве evms, но да, очевидно её надо приводить в соответствие с этими новыми реалиями. 200951 7 rider 2021-07-27 21:08:19 +0300 https://www.altlinux.org/Bug_Severity_Policy 200952 8 aen 2021-07-27 21:11:08 +0300 Как угодно, но мне кажется, что xfs выбирается в установщике "широким кругом пользователей", потому major. 200953 9 rider 2021-07-27 21:11:53 +0300 severity в данном случае никак явно не повлияет ни на что, понятно что это надо поправить к дистрибутивам на p10. 201221 10 mcpain 2021-08-04 16:14:46 +0300 evms при расчёте размера лога берёт количество блоков (=512 байт) целевой ФС, делит его на 8196 (очень странная константа, как минимум тем, что не 8192 = 2^13) и округляет его до 4 мегабайт. Однако в подсказке к параметру evms сам пишет, что размер лога как правило задаётся 0.4% от размера раздела, а расчётный получается в 32 раза меньше. libxfs считает, что размер лога - от 512 блоков (=2М) до (1024 * 1024) блоков (=4G), а evms считает, что 128М - уже много. Придётся патчить и это. 201291 11 mike 2021-08-06 15:44:01 +0300 (Ответ для Олег Соловьев на комментарий #10) > evms при расчёте размера лога берёт количество блоков (=512 байт) целевой > ФС, делит его на 8196 (очень странная константа, как минимум тем, что не > 8192 = 2^13) и округляет его до 4 мегабайт. Возможно, им надо было добиться значения чуть меньше, чем "круглое"? А _не_ передавать вручную размер лога, оставив этот вопрос mkfs.xfs -- можно? 201292 12 mcpain 2021-08-06 15:52:16 +0300 (Ответ для Michael Shigorin на комментарий #11) > Возможно, им надо было добиться значения чуть меньше, чем "круглое"? С учетом последующего округления до мегабайтов - крайне странное решение. (Ответ для Michael Shigorin на комментарий #11) > А _не_ передавать вручную размер лога, оставив этот вопрос mkfs.xfs -- можно? Он не передаётся вручную. Это дефолтное значение в evms. 201299 13 mike 2021-08-06 18:24:19 +0300 Возможно, это всего лишь опечатка. Попытался найти следы вопросов-ответов -- яндекс да гугл ничего внятного по запросу "evms" "xfs" why "8196" not "8192" внятного не выдали; а упоминание 8196 в http://www.kernel.org/doc/mirror/ols2002.pdf (там же и по EVMS был доклад) -- похоже, явная опечатка в ряду: "1024, 2048, 4096, *8196*, 16384, 32768 and 65536" (поскольку без комментариев о причине "особого случая"). 201366 14 mcpain 2021-08-09 18:36:30 +0300 (Ответ для Michael Shigorin на комментарий #13) > -- похоже, явная опечатка в ряду: "1024, 2048, 4096, *8196*, 16384, 32768 > and 65536" (поскольку без комментариев о причине "особого случая"). как я уже писал в комм. 10 - расчётное дефолтное значение logsize в 32 раза меньше указанного в самом evms рекомендуемого 0.4% (~1/256) от размера раздела. Получается 1/8196 от размера раздела, а это слишком мало. Миш, я не хочу отправлять пакет с молчаливого одобрения, поэтому прошу явного. 201376 15 mike 2021-08-10 00:02:56 +0300 Очень бегло заглянул в plugins/xfs/ и мне более уверенно кажется, что попросту не надо указывать mkfs.xfs, какой ей делать журнал, если не было явных пожеланий от клиента libevms (или alterator-vm/guile-evms умеют эту подробность?). Бишь попытки посчитать-влепить свой размер _по умолчанию_ силами evms надо оторвать. Олег, можешь сделать? 201381 16 mcpain 2021-08-10 09:04:51 +0300 (Ответ для Michael Shigorin на комментарий #15) > Олег, можешь сделать? А есть информация, как при этом поведет себя mkfs.xfs? 201388 17 mike 2021-08-10 10:26:11 +0300 mkfs.xfs /dev/sdXN без дополнительных параметров всю жизнь себя нормально вёл: basalt:/tmp/.private/mike> dd if=/dev/zero of=test.img bs=1M count=256 256+0 записей получено 256+0 записей отправлено 268435456 байт (268 MB, 256 MiB) скопирован, 0,107019 s, 2,5 GB/s basalt:/tmp/.private/mike> /sbin/mkfs.xfs test.img meta-data=test.img isize=512 agcount=4, agsize=16384 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=0 inobtcount=0 data = bsize=4096 blocks=65536, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=1368, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 basalt:/tmp/.private/mike> rm test.img basalt:/tmp/.private/mike> _ :-) 201390 18 mcpain 2021-08-10 10:52:42 +0300 (Ответ для Michael Shigorin на комментарий #15) > Очень бегло заглянул в plugins/xfs/ и мне более уверенно кажется, что > попросту не надо указывать mkfs.xfs, какой ей делать журнал, если не было > явных пожеланий от клиента libevms (или alterator-vm/guile-evms умеют эту > подробность?). В коде установки параметра -lsize не делается никакой разницы между значением по умолчанию и значением, прилетевшим от пользователя. Архитектура evms подразумевает, что если имеется какая-то настраиваемая штуковина, то для этой штуковины требуется значение по умолчанию, которое в данный момент зависит от размера раздела. Если пользователь хочет создать раздел и не хочет мудрить с размером, то для пользователя нет никакой разницы, кто будет мудрить за него и какое значение установит, пока это не создаст никаких проблем. Если пользователь хочет свой размер, он его укажет в явном виде. Проблему, описанную в баге, я устранил и намерен отправить изменение. Насчёт хотелки про отгрызание я подумаю, как реализовать, но _не_ в рамках исправления этого бага. Таску отправляю. 201393 19 repository-robot 2021-08-10 11:02:58 +0300 evms-2.5.5-alt50 -> sisyphus: Wed Aug 04 2021 Oleg Solovyov <mcpain@altlinux> 2.5.5-alt50 - plugins/xfs: fix incorrect log size calculation (Closes: #39567) 201394 20 aen 2021-08-10 11:05:15 +0300 Неужто работает? Пожалуйста, тогда в p10. 201395 21 rider 2021-08-10 11:08:44 +0300 Да, отправьте в p10 пожалуйста.