LINUX.ORG.RU
ФорумAdmin

lvresize/lvreduce - странная интерпретация требуемого размера.

 ,


0

1

Ребята, у меня тут что-то лыжи не едут.

Fedora Linux 39
6.6.6-200.fc39.x86_64

temp vg01 -wi-a----- <11.37t

/dev/mapper/vg01-temp   12T  2.5T  8.4T  23% /mnt

Пытаюсь уменьшить том, до 5T, получаю следующий прикол

lvresize -r -L5T /dev/vg01/temp
File system ext4 found on vg01/temp.
File system size (<11.37 TiB) is larger than the requested size (1.00 TiB).
File system reduce is required using resize2fs.
File system fsck will be run before reduce.
Reducing file system ext4 to 1.00 TiB (1099511627776 bytes) on vg01/temp...
e2fsck /dev/vg01/temp
/dev/vg01/temp: 14/381480960 files (0.0% non-contiguous), 679430522/3051815936 blocks
e2fsck done
resize2fs /dev/vg01/temp 1073741824k
resize2fs 1.47.0 (5-Feb-2023)
resize2fs: New size smaller than minimum (663495623)

resize2fs failed
File system reduce failed.
Failed to reduce file system with lvresize_fs_helper.

Если, вначале, уменьшить ФС до 5T(успешно уменьшается), а потом применить lvreduce - получается та же фигня

[root@storage ~]# e2fsck -fy /dev/vg01/temp
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg01/temp: 14/381480960 files (0.0% non-contiguous), 679430522/3051815936 blocks

[root@storage ~]# resize2fs /dev/vg01/temp 5T
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/vg01/temp to 1342177280 (4k) blocks.
The filesystem on /dev/vg01/temp is now 1342177280 (4k) blocks long.

mount /dev/vg01/temp /mnt/; df -h | grep mnt
/dev/mapper/vg01-temp  5.0T  2.5T  2.4T  52% /mnt - ФС уменьшилась

[root@storage ~]# lvreduce -L -5T /dev/vg01/temp
File system ext4 found on vg01/temp.
File system size (5.00 TiB) is larger than the requested size (377.75 GiB).
File system reduce is required (see resize2fs or --resizefs.)

Пробовал отнимать в экстентах, если один PE=4M, то чтобы уменьшить том на 4T, делаю соответственно

[root@storage ~]# lvreduce -l -1000000 /dev/vg01/temp
File system ext4 found on vg01/temp.
File system size (5.00 TiB) is larger than the requested size (1.55 TiB).
File system reduce is required (see resize2fs or --resizefs.)

Вопрос - что происходит? Откуда берутся эти «requested size»? Почему он не такие, как я указываю? В мане к lvresize(reduce) по прежнему указано

UNIT represents other possible input units: b|B is bytes, s|S is sectors of 512 bytes, k|K is KiB, m|M is MiB, g|G is GiB, t|T is TiB, p|P is PiB, e|E is EiB.

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

Проскакивала мысль о том, что виной может быть размер тома, который по дефолту MBR и lvresize отталкивается от размера в 2T, но попробовал провернуть такое же (оба способа) на CentOs7, уменьшив lvm-том с 7T до 5T - прошло как по маслу.

/dev/mapper/vg01-ringbackup  7.0T  2.5T  4.6T  35% /ringback
ringbackup  vg01 -wi-a-----   7.00t

 lvresize -r -L5T /dev/vg01/ringbackup
fsck from util-linux 2.23.2
/dev/mapper/vg01-ringbackup: 112744/234881024 files (34.4% non-contiguous), 666628760/1879048192 blocks
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/vg01-ringbackup to 1342177280 (4k) blocks.
The filesystem on /dev/mapper/vg01-ringbackup is now 1342177280 blocks long.

  Size of logical volume vg01/ringbackup changed from 7.00 TiB (1835008 extents) to 5.00 TiB (1310720 extents).
  Logical volume vg01/ringbackup successfully resized.

 ringbackup  vg01 -wi-a-----   5.00t
/dev/mapper/vg01-ringbackup  5.0T  2.5T  2.6T  49% /ringback




Ну, CentOS7 это стабильная и проверенная система, а Fedora это альфатест для будущей стабильной системы, чего ты хотел. Очевидно там баг. Загрузись с livecd CentOS и сделай всё что надо.

А вообще лучше с lvm с самого начала не связываться.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

чего ты хотел

хотел подтверждения, что не я дурак а проблема действительно в системе, спасибо =)

лучше с lvm с самого начала не связываться

а можно подробностей? использую несколько лет на centos, данные пока не терял.

kreiz
() автор топика
Ответ на: комментарий от kreiz

лучше с lvm с самого начала не связываться

Только если не знаешь как с ним работать. А так действительно удобно работать с разделами не выключая систему. Спокойно можно перенести работающую систему с одного диска на другой без даунтайма.

einhander ★★★★★
()
Ответ на: комментарий от kreiz

Не слушай его. LVM это промышленный стандарт. Не нужно каждому фрику на LOR верить. Ему не нужно, вот пусть он и не использует. Локти грызть потом будет он, а не ты. Хотя грызть их он конечно же не будет, он расскажет тебе про btrfs и zfs, но ты всё таки LVM осваивай, он никуда в ближайшее время не денется. Без него конечно же можно обойтись, но работе он никак не мешает, а в момент когда он внезапно понадобится окажется очень хорошо что он есть.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от Jameson

Ему не нужно, вот пусть он и не использует.

Автору темы не нужно. Всякие так называемые промышленные так называемые стандарты пусть используют те кто их придумал.

, но работе он никак не мешает,

Тему бы прочитал, она как раз о том как федоровские lvm-баги мешают работе. А не было бы lvm-а - не было бы этих проблем.

в момент когда он внезапно понадобится окажется очень хорошо что он есть.

То есть скорее всего никогда.

firkax ★★★★★
()

Странно. А у тебя том случайно не зеркальный? (raid1)

lvs -a
vgdisplay vg01
lvdisplay vg01/temp

В любом случае, при уменьшени раздела с данными я бы внимательно посчитал все в блоках (для resize2fs) и экстентах (для lvresize), причем с запасом (ФС должна быть явно меньше тома)

router ★★★★★
()

Лыжи как раз едут нормально:

[root@fedora ~]# lvscan  | grep big
  ACTIVE            '/dev/bigtest/test' [<1024.00 GiB] inherit


[root@fedora ~]# mkfs.ext4 /dev/bigtest/test
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 268434432 4k blocks and 67108864 inodes
Filesystem UUID: b92107e6-7690-4619-9d04-7ad280ae3673
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
	102400000, 214990848
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

[root@fedora ~]# lvresize -L -400G /dev/bigtest/test
  File system ext4 found on bigtest/test.
  File system size (<1024.00 GiB) is larger than the requested size (<624.00 GiB).
  File system reduce is required (see resize2fs or --resizefs.)


[root@fedora ~]# resize2fs /dev/bigtest/test 500G
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/bigtest/test to 131072000 (4k) blocks.
The filesystem on /dev/bigtest/test is now 131072000 (4k) blocks long.



[root@fedora ~]# lvresize -L -400G /dev/bigtest/test
  File system ext4 found on bigtest/test.
  File system size (500.00 GiB) is smaller than the requested size (<624.00 GiB).
  File system reduce is not needed, skipping.
  Size of logical volume bigtest/test changed from <1024.00 GiB (262143 extents) to <624.00 GiB (159743 extents).
  Logical volume bigtest/test successfully resized.
no-dashi-v2 ★★★
()
[root@storage ~]# resize2fs /dev/vg01/temp 5T

[root@storage ~]# lvreduce -L -5T /dev/vg01/temp

Вот тут ты файловую систему уменьшил до 5Тб. А раздел под неё уменьшил на 5Тб. А было-то сколько, 5.3 Тб?

Но возможно и какой-то глюк, который надо отнести в багтрекер федоры.

Aceler ★★★★★
()
Ответ на: комментарий от no-dashi-v2

Да, на мелких (и пустых!) ФС все едет нормально:

lvscan | grep test
ACTIVE            '/dev/vg01/test' [1.00 TiB] inherit
[root@storage ~]# mkfs.ext4 /dev/vg01/test
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 268435456 4k blocks and 67108864 inodes
Filesystem UUID: a81a1cde-a1b3-4e7b-981b-d6233af0d4b8
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

[root@storage ~]# lvresize -r -L -400G /dev/vg01/test
File system ext4 found on vg01/test.
File system size (1.00 TiB) is larger than the requested size (624.00 GiB).
File system reduce is required using resize2fs.
File system fsck will be run before reduce.
Reducing file system ext4 to 624.00 GiB (670014898176 bytes) on vg01/test...
e2fsck /dev/vg01/test
/dev/vg01/test: 12/67108864 files (0.0% non-contiguous), 4495258/268435456 blocks
e2fsck done
resize2fs /dev/vg01/test 654311424k
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/vg01/test to 163577856 (4k) blocks.
The filesystem on /dev/vg01/test is now 163577856 (4k) blocks long.

resize2fs done
Reduced file system ext4 on vg01/test.
Size of logical volume vg01/test changed from 1.00 TiB (262144 extents) to 624.00 GiB (159744 extents).
Logical volume vg01/test successfully resized.

А попробуй сделать вот так:

lvscan | grep temp
ACTIVE            '/dev/vg01/temp' [10.00 TiB] inherit

mkfs.ext4 /dev/vg01/temp
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 2684354560 4k blocks and 335544320 inodes
Filesystem UUID: 8486faf2-99de-48b0-afea-7044adc03a1f
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
2560000000

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

[root@storage ~]# mount /dev/vg01/temp /mnt/

dd if=/dev/zero of=/mnt/file2 bs=200M count=20000 status=progress
4194304000000 bytes (4.2 TB, 3.8 TiB) copied, 21401 s, 196 MB/s
20000+0 records in
20000+0 records out
4194304000000 bytes (4.2 TB, 3.8 TiB) copied, 21401.4 s, 196 MB/s

[root@storage ~]# umount -l /mnt/

[root@storage ~]# lvresize -r -L5T /dev/vg01/temp
File system ext4 found on vg01/temp.
File system size (10.00 TiB) is larger than the requested size (1.00 TiB).
File system reduce is required using resize2fs.
File system fsck will be run before reduce.
Reducing file system ext4 to 1.00 TiB (1099511627776 bytes) on vg01/temp...
e2fsck /dev/vg01/temp
/dev/vg01/temp: 13/335544320 files (0.0% non-contiguous), 1045447293/2684354560 blocks
e2fsck done
resize2fs /dev/vg01/temp 1073741824k
resize2fs 1.47.0 (5-Feb-2023)
resize2fs: New size smaller than minimum (1036124998)

resize2fs failed
File system reduce failed.
Failed to reduce file system with lvresize_fs_helper.


kreiz
() автор топика

А попробуй уменьшать в несколько шагов. Сначала на 1TB, потом снова на 1TB.

А то уж больно смахивает на переполнение 32-битного целого. 5TB-2^32 = 1TB (ты уменьшаешь на 5TB, а он откуда-то взял requested size=1TB).

bigbit ★★★★★
()
Ответ на: комментарий от firkax

Ты несешь полную ахинею о том, что LVM якобы не нужен на форуме, где куча админов на личном опыте знают о его пользе. И они тебе уже много раз говорили об этом.

Ты хуже чем виндотролли. Они лишь флудят, а ты даешь вредные советы.

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

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от firkax

А, кажется понял, в чем дело… ты разработчик, а не админ.

Так вот, у нас тут своя кухня. Это у тебя мир концептуально идеальных и красивых решений.

У нас тут — сервер поставлен годы назад, даунтайм не согласовать, нужно расширить место на разделах в середине диска, и заранее никто не планировал, что это будет нужно.

И это просто обычное дело. Можешь называть это нищебродством, неправильным планированием разметки и места, экономией байт — но это то, как на самом деле постоянно бывает.

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от bigbit

А попробуй уменьшать в несколько шагов. Сначала на 1TB, потом снова на 1TB.

Пробую уменьшать хоть на 100G, получаю ту же ерунду в ответ

[root@storage ~]# lvresize -r -L9.9T /dev/vg01/temp
Rounding size to boundary between physical extents: 9.90 TiB.
File system ext4 found on vg01/temp.
File system size (10.00 TiB) is larger than the requested size (1.90 TiB).
File system reduce is required using resize2fs.
File system fsck will be run before reduce.
Reducing file system ext4 to 1.90 TiB (2089073770496 bytes) on vg01/temp...
e2fsck /dev/vg01/temp
/dev/vg01/temp: 13/335544320 files (0.0% non-contiguous), 1045447293/2684354560 blocks
e2fsck done
resize2fs /dev/vg01/temp 2040111104k
resize2fs 1.47.0 (5-Feb-2023)
resize2fs: New size smaller than minimum (1036124998)

resize2fs failed
File system reduce failed.
Failed to reduce file system with lvresize_fs_helper.

[root@storage ~]# lvreduce -L -100G /dev/vg01/temp
File system ext4 found on vg01/temp.
File system size (5.00 TiB) is larger than the requested size (1.90 TiB).
File system reduce is required (see resize2fs or --resizefs.)

А то уж больно смахивает на переполнение 32-битного целого.

как уже писал выше - на centos такие же манипуляции отрабатывают как положено

[root@kvm2 /]# lvs | grep ring
  ringbackup  vg01 -wi-a-----   8.15t
[root@kvm2 /]# lvresize -r -L5T /dev/vg01/ringbackup
fsck from util-linux 2.23.2
/dev/mapper/vg01-ringbackup: 33845/273539072 files (1.0% non-contiguous), 322361429/2188303360 blocks
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/vg01-ringbackup to 1342177280 (4k) blocks.
The filesystem on /dev/mapper/vg01-ringbackup is now 1342177280 blocks long.

  Size of logical volume vg01/ringbackup changed from 8.15 TiB (2137015 extents) to 5.00 TiB (1310720 extents).
  Logical volume vg01/ringbackup successfully resized.
[root@kvm2 /]# lvs | grep ring
  ringbackup  vg01 -wi-a-----   5.00t
kreiz
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

И это просто обычное дело.
Можешь называть это нищебродством, неправильным планированием разметки и места
но это то, как на самом деле постоянно бывает.

Вы про нищебродство и неправильное планирование? Да, такая фигня везде во все поля.

anc ★★★★★
()
Ответ на: комментарий от Vsevolod-linuxoid

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

anonymous
()
Ответ на: комментарий от anonymous

нормального

LVM thin

Толсто. Фейковое блочное устройство, которое не гарантирует, что сможет предоставить место под запись, если соседний том всё высосет, это просто мусор.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Фейковое блочное устройство, которое не гарантирует, что сможет предоставить место под запись, если соседний том всё высосет, это просто мусор.

Not sure if trolling or just stupid©

Не делай тома больше, чем у тебя есть места, и всё будет хорошо. Это в большинстве случаев очень сомнительная фича, которая никому и не навязывается (кроме говноедов-пользователей покойного Stratis).

anonymous
()
Ответ на: комментарий от anonymous

Не делай тома больше, чем у тебя есть места, и всё будет хорошо.

Не пользуйся lvm thin и всё будет хорошо. Это ж надо было запроектировать ружьё направленное прямо в ногу, а потом писать нунеделайтетакибудетхорошо.

ox55ff ★★★★★
()
12 мая 2024 г.

У меня ровно такая же ситуация. Где-то на Stack Overflow пробежала инфа про –fs=ignore, но было боязно с этой опцией запускать. Ну и потом обнаружилось, что sys-fs/lvm2-2.03.22-r5-1::gentoo был не пропатчен по 32-bit overflow на lp->extents.

Для себя я решил проблему так: ручками поправил место в исходниках (см урл на патчик ниже) - lvm2, ebuild … compile, install, qmerge И после этого lvreduce dev newsize нормально отработал (и показал адекватное предупреждение о размере).

А патчик https://gitlab.com/lvmteam/lvm2/-/commit/fa496513010976aac21584b5081529b76462f9a9 не применялся - потому что тесты «не проходили». Но не проходили они не потому, что с ошибкой было чтото закоммичено, а потому что сборочный-проверочный сервер был/есть тормозной и все 8 месяцев после коммита он пытался протестировать, но делал это медленно, более 2 часов, за что кикался и тест обламывался. Мейнтейнеры не возбуждались.

mcgru
()