В инсталяторе не работает форматирование в xfs. Проблема началась после обновления xfsprogs до версии 5.9.0-alt1.
Плагин для работы с файловой системой 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
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
(Ответ для 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 Есть предложения?
(Ответ для 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, какие ещё могут быть варианты?
(In reply to Anton V. Boyarshinov from comment #4) > (Ответ для AEN на комментарий #3) > > Есть предложения? > Надо менять ecms, какие ещё могут быть варианты? Видимо имелось ввиду патчить xfs-плагин libevms?
(Ответ для Leonid Krivoshein на комментарий #5) > (In reply to Anton V. Boyarshinov from comment #4) > > (Ответ для AEN на комментарий #3) > > > Есть предложения? > > Надо менять ecms, какие ещё могут быть варианты? > Видимо имелось ввиду патчить xfs-плагин libevms? Я не имею ни малейшего представления о внутреннем устройстве evms, но да, очевидно её надо приводить в соответствие с этими новыми реалиями.
https://www.altlinux.org/Bug_Severity_Policy
Как угодно, но мне кажется, что xfs выбирается в установщике "широким кругом пользователей", потому major.
severity в данном случае никак явно не повлияет ни на что, понятно что это надо поправить к дистрибутивам на p10.
evms при расчёте размера лога берёт количество блоков (=512 байт) целевой ФС, делит его на 8196 (очень странная константа, как минимум тем, что не 8192 = 2^13) и округляет его до 4 мегабайт. Однако в подсказке к параметру evms сам пишет, что размер лога как правило задаётся 0.4% от размера раздела, а расчётный получается в 32 раза меньше. libxfs считает, что размер лога - от 512 блоков (=2М) до (1024 * 1024) блоков (=4G), а evms считает, что 128М - уже много. Придётся патчить и это.
(Ответ для Олег Соловьев на комментарий #10) > evms при расчёте размера лога берёт количество блоков (=512 байт) целевой > ФС, делит его на 8196 (очень странная константа, как минимум тем, что не > 8192 = 2^13) и округляет его до 4 мегабайт. Возможно, им надо было добиться значения чуть меньше, чем "круглое"? А _не_ передавать вручную размер лога, оставив этот вопрос mkfs.xfs -- можно?
(Ответ для Michael Shigorin на комментарий #11) > Возможно, им надо было добиться значения чуть меньше, чем "круглое"? С учетом последующего округления до мегабайтов - крайне странное решение. (Ответ для Michael Shigorin на комментарий #11) > А _не_ передавать вручную размер лога, оставив этот вопрос mkfs.xfs -- можно? Он не передаётся вручную. Это дефолтное значение в evms.
Возможно, это всего лишь опечатка. Попытался найти следы вопросов-ответов -- яндекс да гугл ничего внятного по запросу "evms" "xfs" why "8196" not "8192" внятного не выдали; а упоминание 8196 в http://www.kernel.org/doc/mirror/ols2002.pdf (там же и по EVMS был доклад) -- похоже, явная опечатка в ряду: "1024, 2048, 4096, *8196*, 16384, 32768 and 65536" (поскольку без комментариев о причине "особого случая").
(Ответ для Michael Shigorin на комментарий #13) > -- похоже, явная опечатка в ряду: "1024, 2048, 4096, *8196*, 16384, 32768 > and 65536" (поскольку без комментариев о причине "особого случая"). как я уже писал в комм. 10 - расчётное дефолтное значение logsize в 32 раза меньше указанного в самом evms рекомендуемого 0.4% (~1/256) от размера раздела. Получается 1/8196 от размера раздела, а это слишком мало. Миш, я не хочу отправлять пакет с молчаливого одобрения, поэтому прошу явного.
Очень бегло заглянул в plugins/xfs/ и мне более уверенно кажется, что попросту не надо указывать mkfs.xfs, какой ей делать журнал, если не было явных пожеланий от клиента libevms (или alterator-vm/guile-evms умеют эту подробность?). Бишь попытки посчитать-влепить свой размер _по умолчанию_ силами evms надо оторвать. Олег, можешь сделать?
(Ответ для Michael Shigorin на комментарий #15) > Олег, можешь сделать? А есть информация, как при этом поведет себя mkfs.xfs?
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> _ :-)
(Ответ для Michael Shigorin на комментарий #15) > Очень бегло заглянул в plugins/xfs/ и мне более уверенно кажется, что > попросту не надо указывать mkfs.xfs, какой ей делать журнал, если не было > явных пожеланий от клиента libevms (или alterator-vm/guile-evms умеют эту > подробность?). В коде установки параметра -lsize не делается никакой разницы между значением по умолчанию и значением, прилетевшим от пользователя. Архитектура evms подразумевает, что если имеется какая-то настраиваемая штуковина, то для этой штуковины требуется значение по умолчанию, которое в данный момент зависит от размера раздела. Если пользователь хочет создать раздел и не хочет мудрить с размером, то для пользователя нет никакой разницы, кто будет мудрить за него и какое значение установит, пока это не создаст никаких проблем. Если пользователь хочет свой размер, он его укажет в явном виде. Проблему, описанную в баге, я устранил и намерен отправить изменение. Насчёт хотелки про отгрызание я подумаю, как реализовать, но _не_ в рамках исправления этого бага. Таску отправляю.
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)
Неужто работает? Пожалуйста, тогда в p10.
Да, отправьте в p10 пожалуйста.
