Created attachment 8348 [details]
Некорректное отображение свободного места раздела vfat

Как выяснилось - причина в немного некорректном поведении утилиты fatresize, которая вызывается в плагине fat в libevms. 

fatresize считает, что минимальный размер fat32 партиции - 512 МиБ. Из readme к fatresize, я понял, что это сделано в угоду совместимости с Windows, потому что он якобы не умеет правильно работать с fat32 партициями размером меньше 512 МиБ. 

Что странно - это ограничение затрагивает не только задание размера fat32-партиции, но и вывод информации об уже созданной. Отсюда и неверное поведение. 

Например, для партиции размером 256 МиБ fatresize покажет "Min size: 536870912" (512 МиБ), а потом в alterator-vm от 256 отнимется 512. И в итоге мы имеем -256 МиБ свободного места.

В общем, я напишу разработчикам fatresize и отпишусь по результатам.

Спасибо за раскопки!

2 nickel: к теме UEFI это имеет прямое отношение в том смысле, что обычно alterator-vm делает FAT32 для /boot/efi/ -- может иметь смысл провентилировать вопрос да проверить фактическую совместимость ровно по этой части.

(В ответ на комментарий №2)
> В общем, я напишу разработчикам fatresize
Дело в том, что это ты. ;-) mouse@ у нас давно не работает, а led@ разработкой не занимался.

(В ответ на комментарий №4)
> (В ответ на комментарий №2)
> > В общем, я напишу разработчикам fatresize
> Дело в том, что это ты. ;-) mouse@ у нас давно не работает, а led@ разработкой
> не занимался.

Тогда, сделаю так: добавлю в fatresize дополнительную опцию, при появлении которой он работает без ограничения в 512 МиБ

(В ответ на комментарий №5)
> (В ответ на комментарий №4)
> > (В ответ на комментарий №2)
> > > В общем, я напишу разработчикам fatresize
> > Дело в том, что это ты. ;-) mouse@ у нас давно не работает, а led@ разработкой
> > не занимался.
> 
> Тогда, сделаю так: добавлю в fatresize дополнительную опцию, при появлении
> которой он работает без ограничения в 512 МиБ

Да уберите это ограничение вообще и не мучайтесь.

Убрал ограничение. Все заработало нормально для разделов > 260 MиБ. Для разделов меньше 260 МиБ теперь новый прикол - в качестве заполненного места возвращается размер раздела + 64 сектора (что не соответствует действительности).

Как я понял, дело тут в том, что libparted не умеет нормально работать с fat32 разделами, если количество секторов на кластер у них меньше 4. mkfs.fat -F32 для разделов < 260 МиБ как раз устанавливает 1 сектор на кластер (если > 260 то 8). Ограничение связано с самим fat'ом - fat32 не может быть меньше 65,527 кластеров.

В libparted есть ограничения на минимальное количество секторов на кластер. Если для fat32 установить его в 1, то все заработает нормально, но я пока не знаю, не сломается ли от этого что-то еще. Вот тут есть и один странный момент - fat32 в libparted ограничивают восьмью секторами на кластер, но все прекрасно работает с разделами, где 4 сектора на кластер. Это надо проверить, но мне кажется, что libparted в данном случае работает с fat32 разделами как с fat16 (?!).

В общем, я пока не придумал нормальное решение этой проблемы. Самое простое ненормальное - это сделать так, чтобы mkfs.fat устанавливал 4 сектора на кластер для разделов больших 130 МиБ и меньших 260 МиБ. Ну и никогда не создавать fat32 разделы меньше 130 МиБ :)

И есть еще одно. Почти нормальное. В GParted данная проблема не проявляется, т.к. для получения информации о fat разделе он использует свою внутреннюю реализацию. По сути это вызов fsck.fat -n -v, и вышеописанных проблем у него нет. Отсюда второй вариант - для получения размера раздела использовать fsck.fat -n -v прям из плагина fat для evms вместо fatresize.

последний вариант мне нравится больше всего. Но fatresize вероятно используется ещё для чего-то помимо получения размера (например для его изменения). И что будет с этим функционалом ?

(В ответ на комментарий №8)
> последний вариант мне нравится больше всего. Но fatresize вероятно используется
> ещё для чего-то помимо получения размера (например для его изменения). И что
> будет с этим функционалом ?

Никаких проблем быть не должно. Изменение размера останется с помощью fatresize (а под ним - вызовы libparted), получение размера будет с помощью fsck.fat.

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

Думаю, что надо реализовать и потестировать.

В общем, проблема устранена.
Убрал ограничение в 512 МиБ в fatresize: http://git.altlinux.org/people/ptrnine/packages/?p=fatresize.git;a=commit;h=421dd52d9b2aac7a96b1954499cf8d5282812ce6

Плагин fat в evms претерпел более серьезные изменения: http://git.altlinux.org/people/ptrnine/packages/?p=evms.git;a=commit;h=1887dc9008acbf817c930e84020530a6a30d354f

Вместо fatresize для нахождения допустимых пределов изменения размера fat-партиций теперь изпользуются утилиты fdisk, lsblk и fsck.fat

Для нахождения нижнего предела используется "fsck.fat -n". Из вывода данной утилиты выдергиваются кол-во занятых и свободных кластеров.

C верхним пределом получилось немного сложнее. libparted в качестве него возвращал просто размер устройства, на котором находится партиция. Теперь все работает так:
1. Вызывается 'lsblk -anprs -o NAME /dev/*'для нахождения устройства, на котором находится партиция. В выводе оно оказывается на последней строчке (например, для /dev/sda4 родителем будет /dev/sda, для /dev/nvme0n1p2 - /dev/nvme0n1)
2. Далее для устройства-родителя вызывается 'fdisk -o Device,Start -l' который выводит таблицу разделов. Из этой таблицы сначала выдергивается начальный сектор нашей fat-партиции, затем выполняется поиск ближайшей следующей партиции на устройстве. В итоге верхний предел находится как "Начальный сектор партиции" минус "Начальный сектор следующей партиции". Если следующей партиции не существует - то просто используется размер устройства.

В процессе проверки об

Не дописал :)

В процессе тестирования обнаружились новые проблемы. Во-первых - не работает изменение размера для fat lvm-партиций. Тут дело не в исправлении, раньше оно тоже не работало.
Во-вторых - libparted не может изменять размер у больших партиций.
Что делать со второй проблемой - я не знаю, над lvm пока думаю.

Обнаружил в чем проблема с lvm.

evms для /dev/mapper/* устройств устанавливает имена с вертикальными слэшами, например: "lvm2|vg-test|lv-test"

У lvm2 есть механизм, который заменяет недопустимые символы на их шестнадцатеричное значение.
Вертикальный слэш в список допустимых не входит, отсюда вот такая ошибка:

The name " should be mangled but it contains blacklisted characters.

И тут два варианта, либо добавлять вертикальный слэш вот сюда: 
http://git.altlinux.org/gears/l/lvm2.git?p=lvm2.git;a=blob;f=libdm/libdm-common.c;h=1cb29f1e895e6d3cdf33dfb375fe1bcfd7aa9dc5;hb=HEAD#l390
что не очень хорошо

Либо менять вертикальный слэш в evms на что-нибудь еще:
http://git.altlinux.org/gears/e/evms.git?p=evms.git;a=blob;f=engine/dm-ioctl4.c;h=36e3167701e7134a4212817e1d637fb22bbc020e;hb=HEAD#l40

Второй вариант правильнее, потому как именно evms и виноват.
Также неизвестно, какие проблемы могут всплыть после этой замены. Поэтому нужно тщательно протестировать.

И кстати, сама проблема уже не нова, и встречалась вот в этом баге #28020

2sbolshakov: есть мысли по этому поводу ?

(In reply to comment #13)
> Обнаружил в чем проблема с lvm.
> 
> evms для /dev/mapper/* устройств устанавливает имена с вертикальными слэшами,
> например: "lvm2|vg-test|lv-test"
> 
> У lvm2 есть механизм, который заменяет недопустимые символы на их
> шестнадцатеричное значение.
> Вертикальный слэш в список допустимых не входит, отсюда вот такая ошибка:
> 
> The name " should be mangled but it contains blacklisted characters.
> 
> И тут два варианта, либо добавлять вертикальный слэш вот сюда: 
> http://git.altlinux.org/gears/l/lvm2.git?p=lvm2.git;a=blob;f=libdm/libdm-common.c;h=1cb29f1e895e6d3cdf33dfb375fe1bcfd7aa9dc5;hb=HEAD#l390
> что не очень хорошо
> 
> Либо менять вертикальный слэш в evms на что-нибудь еще:
> http://git.altlinux.org/gears/e/evms.git?p=evms.git;a=blob;f=engine/dm-ioctl4.c;h=36e3167701e7134a4212817e1d637fb22bbc020e;hb=HEAD#l40
> 
> Второй вариант правильнее, потому как именно evms и виноват.
> Также неизвестно, какие проблемы могут всплыть после этой замены. Поэтому нужно
> тщательно протестировать.
> 
> И кстати, сама проблема уже не нова, и встречалась вот в этом баге #28020

прошу объяснить, каким образом тут lvm2 появился ?

(В ответ на комментарий №15)
> (In reply to comment #13)
> > Обнаружил в чем проблема с lvm.
> > 
> > evms для /dev/mapper/* устройств устанавливает имена с вертикальными слэшами,
> > например: "lvm2|vg-test|lv-test"
> > 
> > У lvm2 есть механизм, который заменяет недопустимые символы на их
> > шестнадцатеричное значение.
> > Вертикальный слэш в список допустимых не входит, отсюда вот такая ошибка:
> > 
> > The name " should be mangled but it contains blacklisted characters.
> > 
> > И тут два варианта, либо добавлять вертикальный слэш вот сюда: 
> > http://git.altlinux.org/gears/l/lvm2.git?p=lvm2.git;a=blob;f=libdm/libdm-common.c;h=1cb29f1e895e6d3cdf33dfb375fe1bcfd7aa9dc5;hb=HEAD#l390
> > что не очень хорошо
> > 
> > Либо менять вертикальный слэш в evms на что-нибудь еще:
> > http://git.altlinux.org/gears/e/evms.git?p=evms.git;a=blob;f=engine/dm-ioctl4.c;h=36e3167701e7134a4212817e1d637fb22bbc020e;hb=HEAD#l40
> > 
> > Второй вариант правильнее, потому как именно evms и виноват.
> > Также неизвестно, какие проблемы могут всплыть после этой замены. Поэтому нужно
> > тщательно протестировать.
> > 
> > И кстати, сама проблема уже не нова, и встречалась вот в этом баге #28020
> 
> прошу объяснить, каким образом тут lvm2 появился ?

Именно по этой причине не работает (и не работал) ресайз, если fat-партиция на lvm'е.
А еще, как оказалось, fat-партиции на lvm'e вообще не определяются как fat.

К сабжу это отношения не имеет, поэтому мне стоит создать отдельный баг.

в evms своя реализация lvm.

(В ответ на комментарий №17)
> в evms своя реализация lvm.

Да, но изменение размера fat-партиций все равно происходит через fatresize, который в свою очередь уже вызывает libparted, а потом дело доходит и до самого lvm2.

Ошибка воспроизводится, если на стадии разметки дисков, на любой lvm2 раздел в /dev/mapper/ или /dev/evms/lvm2/ вызывать команду fatresize -i или parted:
fatresize -i /dev/mapper/lvm2_vg_root_lv_vol
или
parted /dev/mapper/lvm2_vg_root_lv_vol

Вот что получаем:
The name "/dev/mapper/lvm2|vg_root|lv_vol" should be mangled but it contains blacklisted characters.

task #242568