Плагин для работы с файловой системой 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 пожалуйста.