Bug 39567 - В инсталяторе не работает форматирование в xfs
Summary: В инсталяторе не работает форматирование в xfs
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: libevms (show other bugs)
Version: unstable
Hardware: all Linux
: P5 normal
Assignee: Олег Соловьев
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 33000 40561
  Show dependency tree
 
Reported: 2021-01-19 18:55 MSK by Антон Мидюков
Modified: 2021-08-10 11:08 MSK (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Антон Мидюков 2021-01-19 18:55:54 MSK
В инсталяторе не работает форматирование в xfs. Проблема началась после обновления xfsprogs до версии 5.9.0-alt1.
Comment 1 Антон Мидюков 2021-06-09 01:09:52 MSK
Плагин для работы с файловой системой 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
Comment 2 Slava Aseev 2021-07-23 14:37:25 MSK
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
Comment 3 AEN 2021-07-23 20:11:26 MSK
(Ответ для 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

Есть предложения?
Comment 4 Anton V. Boyarshinov 2021-07-26 10:52:53 MSK
(Ответ для 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, какие ещё могут быть варианты?
Comment 5 Leonid Krivoshein 2021-07-26 21:59:20 MSK
(In reply to Anton V. Boyarshinov from comment #4)
> (Ответ для AEN на комментарий #3)
> > Есть предложения?
> Надо менять ecms, какие ещё могут быть варианты?
Видимо имелось ввиду патчить xfs-плагин libevms?
Comment 6 Anton V. Boyarshinov 2021-07-27 11:10:23 MSK
(Ответ для Leonid Krivoshein на комментарий #5)
> (In reply to Anton V. Boyarshinov from comment #4)
> > (Ответ для AEN на комментарий #3)
> > > Есть предложения?
> > Надо менять ecms, какие ещё могут быть варианты?
> Видимо имелось ввиду патчить xfs-плагин libevms?

Я не имею ни малейшего представления о внутреннем устройстве evms, но да, очевидно её  надо приводить в соответствие с этими новыми реалиями.
Comment 7 Anton Farygin 2021-07-27 21:08:19 MSK
https://www.altlinux.org/Bug_Severity_Policy
Comment 8 AEN 2021-07-27 21:11:08 MSK
Как угодно, но мне кажется, что xfs выбирается в установщике "широким кругом пользователей", потому major.
Comment 9 Anton Farygin 2021-07-27 21:11:53 MSK
severity в данном случае никак явно не повлияет ни на что, понятно что это надо поправить к дистрибутивам на p10.
Comment 10 Олег Соловьев 2021-08-04 16:14:46 MSK
evms при расчёте размера лога берёт количество блоков (=512 байт) целевой ФС, делит его на 8196 (очень странная константа, как минимум тем, что не 8192 = 2^13) и округляет его до 4 мегабайт.

Однако в подсказке к параметру evms сам пишет, что размер лога как правило задаётся 0.4% от размера раздела, а расчётный получается в 32 раза меньше.

libxfs считает, что размер лога - от 512 блоков (=2М) до (1024 * 1024) блоков (=4G), а evms считает, что 128М - уже много.

Придётся патчить и это.
Comment 11 Michael Shigorin 2021-08-06 15:44:01 MSK
(Ответ для Олег Соловьев на комментарий #10)
> evms при расчёте размера лога берёт количество блоков (=512 байт) целевой
> ФС, делит его на 8196 (очень странная константа, как минимум тем, что не
> 8192 = 2^13) и округляет его до 4 мегабайт.

Возможно, им надо было добиться значения чуть меньше, чем "круглое"?
А _не_ передавать вручную размер лога, оставив этот вопрос mkfs.xfs -- можно?
Comment 12 Олег Соловьев 2021-08-06 15:52:16 MSK
(Ответ для Michael Shigorin на комментарий #11)
> Возможно, им надо было добиться значения чуть меньше, чем "круглое"?
С учетом последующего округления до мегабайтов - крайне странное решение.


(Ответ для Michael Shigorin на комментарий #11)
> А _не_ передавать вручную размер лога, оставив этот вопрос mkfs.xfs -- можно?
Он не передаётся вручную. Это дефолтное значение в evms.
Comment 13 Michael Shigorin 2021-08-06 18:24:19 MSK
Возможно, это всего лишь опечатка.  Попытался найти следы вопросов-ответов -- яндекс да гугл ничего внятного по запросу "evms" "xfs" why "8196" not "8192" внятного не выдали; а упоминание 8196 в http://www.kernel.org/doc/mirror/ols2002.pdf (там же и по EVMS был доклад) -- похоже, явная опечатка в ряду: "1024, 2048, 4096, *8196*, 16384, 32768 and 65536" (поскольку без комментариев о причине "особого случая").
Comment 14 Олег Соловьев 2021-08-09 18:36:30 MSK
(Ответ для Michael Shigorin на комментарий #13)
> -- похоже, явная опечатка в ряду: "1024, 2048, 4096, *8196*, 16384, 32768
> and 65536" (поскольку без комментариев о причине "особого случая").

как я уже писал в комм. 10 - расчётное дефолтное значение logsize в 32 раза меньше указанного в самом evms рекомендуемого 0.4% (~1/256) от размера раздела.

Получается 1/8196 от размера раздела, а это слишком мало.

Миш, я не хочу отправлять пакет с молчаливого одобрения, поэтому прошу явного.
Comment 15 Michael Shigorin 2021-08-10 00:02:56 MSK
Очень бегло заглянул в plugins/xfs/ и мне более уверенно кажется, что попросту не надо указывать mkfs.xfs, какой ей делать журнал, если не было явных пожеланий от клиента libevms (или alterator-vm/guile-evms умеют эту подробность?).

Бишь попытки посчитать-влепить свой размер _по умолчанию_ силами evms надо оторвать.

Олег, можешь сделать?
Comment 16 Олег Соловьев 2021-08-10 09:04:51 MSK
(Ответ для Michael Shigorin на комментарий #15)
> Олег, можешь сделать?

А есть информация, как при этом поведет себя mkfs.xfs?
Comment 17 Michael Shigorin 2021-08-10 10:26:11 MSK
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> _

:-)
Comment 18 Олег Соловьев 2021-08-10 10:52:42 MSK
(Ответ для Michael Shigorin на комментарий #15)
> Очень бегло заглянул в plugins/xfs/ и мне более уверенно кажется, что
> попросту не надо указывать mkfs.xfs, какой ей делать журнал, если не было
> явных пожеланий от клиента libevms (или alterator-vm/guile-evms умеют эту
> подробность?).

В коде установки параметра -lsize не делается никакой разницы между значением по умолчанию и значением, прилетевшим от пользователя.

Архитектура evms подразумевает, что если имеется какая-то настраиваемая штуковина, то для этой штуковины требуется значение по умолчанию, которое в данный момент зависит от размера раздела.

Если пользователь хочет создать раздел и не хочет мудрить с размером, то для пользователя нет никакой разницы, кто будет мудрить за него и какое значение установит, пока это не создаст никаких проблем.

Если пользователь хочет свой размер, он его укажет в явном виде.

Проблему, описанную в баге, я устранил и намерен отправить изменение.
Насчёт хотелки про отгрызание я подумаю, как реализовать, но _не_ в рамках исправления этого бага.

Таску отправляю.
Comment 19 Repository Robot 2021-08-10 11:02:58 MSK
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)
Comment 20 AEN 2021-08-10 11:05:15 MSK
Неужто работает? 
Пожалуйста, тогда в p10.
Comment 21 Anton Farygin 2021-08-10 11:08:44 MSK
Да, отправьте в p10 пожалуйста.