Насколько актуален LVM на десктопе?

LVM удобен большей гибкостью. Например, ты выделил под / всего 10 гигабайт, но потом выяснилось, что нужно больше из-за Snap и Flatpak – если есть свободное место в VG, просто расширяем на ходу LV, если нет – можно скажем swap пожать или /home, если он в ext4, пусть и с перемонтированием…

При этом неважно, в каком месте геометрии диска свободное место. В отличии от стандартных разметок, где если в начале диска /, потом /home, потом swap – а ты хочешь уменьшить swap в пользу /, тебе придется туго – в LVM это элементарно и на ходу.

Или можно скажем миграцию со старого HDD на новый проводить путем pvmove прямо на ходу. Можно делать RAID, 0 и 1 уровень работает хорошо.

Но, к сожалению, в популярных десктопных Linux он остался в установщиках только в Debian, Fedora, RHEL и клонах – из Ubuntu Desktop выпилили, а в популярном Calamares установщике поддержка LVM хотя и есть, но по факту не работает.

Если ты не знаешь, зачем тебе это может быть нужно, то, может, не стоит и думать в эту сторону?

Можно делать RAID, 0 и 1 уровень работает хорошо.

Хорошо ли? Я когда-то сделал зеркало силами LVM, так массив при каждой загрузке заново синхронизировался, и это штатное поведение. Зеркало сделанное mdadm’ом так себя не вело.

массив при каждой загрузке заново синхронизировался

Это у тебя какие-то проблемы с кармой или руками. Как бы не тысячи LVшек в проде видел держали, ни на одной никаких проблем.

Учитывая, что это единственный способ иметь шифрование на актуальной разметке диска – очень актуален.

Пользуюсь, удобно. Мигрировал через несколько HDD и SSD без переустановки. Также пользуюсь lvmcache. Thin provisioning оказался неудобен - нельзя уменьшить, а при сбоях питания он долго пересобирается.

LVM - лишнее усложнение. Если у тебя нет конкретных причин его использовать (которые ты уже сам заранее знаешь) - значит не используй.

единственный

С чего бы это?

выделил под / всего 10 гигабайт, но потом выяснилось, что нужно больше из-за Snap и Flatpak

Нет, не выяснилось. Штуки которые жрут место не надо класть в /. Создаёшь ещё раздел и монтируешь его туда где эти штуки хранят свой мусор.

Если ты не знаешь, зачем тебе это может быть нужно, то, может, не стоит и думать в эту сторону?

Разве это не повод узнать\покопаться?)

Штуки которые жрут место не надо класть в /.

Софтописателями это расскажите, а то вроде и не кадёшь, а потом хоба - и выясняется :)

По сабжу - поддерживаю первый коммент, есть фичи, удобные для десктопа.

Разве это не повод узнать\покопаться?)

Да. Но сначала именно узнать, что это, зачем нужно и что даёт.

ЯТП, для домохозяйских задач это оверхед. И да, не надо под / заводить 10 Гб, актуальные диски сейчас от 512 стартуют, выделяй сразу 100 Гб, не жмоться.

Если тебе вдруг захочется запустить гостевую машину, то LVM будет желательной опцией. Да, можно образ диска машины на файловой системе хоста. НО. В этом случае всегда происходит двойная работа. В случае же LVM гость получает практически прямой доступ к блочному устройству.

Как вариант, попробуй btrfs

А зачем для этого LVM. Доступ к блочному устройству у виртуалок и так есть, без всякого LVM. Накатил виртуалку на раздел диска, и все. Или о чем-то другом речь?

Можно, но не вижу смысла. Отдельные разделы полезны, да, например для быстрой переустановки ОС имеет смысл отдельный /home на десктопе, а на веб-сервере имеет смысл вынести /var/www, чтобы файлы апача не забили корень в процессе работы.

Но Snap и Flatpak – это тоже часть ОС+установленный приклад, что не меняется сама по себе в размерах вне обновлений ПО. На десктопе их проще держать вместе.

Попробовать LVM или оставить просто физические разделы?

Одно другому не мешает.
Т.е. корень на LVM это на мой взгляд скорее переусложнение, а вот разделы с данными - вполне себе.
Плюс в том, что размер логических разделов на LVM проще менять чем таблицу физических разделов.
Из доп. плюшек - можно объединить в логический раздел физические разделы на разных носителях (полезно, когда нужно сделать клон ФС, но нет носителей достаточного размера). Снапшоты и CoW - можно например запустить вирт. машину на raw разделе, но так чтобы измененные данные сохранялись отдельно, не меняя оригинальный раздел.

Многое из того, что может LVM, сейчас можно также получить средствами BTRFS.

Единственная причина, ради которой имеет смысл отказаться от LVM – проще восстанавливать файлы с побитого диска на стандартной разметке и ext4.

В остальном он очень легкий по ресурсам и дает гибкость. А ты предлагаешь, ЕМНИП, на каждый чих покупать новый HDD или разбивать с нуля.

Можно, но рулить LV удобнее, чем обычными разделами.

Например, у тебя 3 раздела по 20 гигов в начале диска, и 100 гигов свободно в конце. Первый из 3 разделов нужно увеличить до 50 гигов.

С LVM это делается на ходу. С классической разметкой – с кучей боли.

Есть, но без thin-provisioning. Ну и более простой resize в случае LVM, т.е. управлять размерами логических томов может сам гипервизор в рамках выделенной volume group.

И как тогда узнавать новое? Зачем вообще тогда Linux использовать?

А вот выделил я просто огромное пространство в 30гб под рут. А оказалось, что оно не такое уж и огромное, даже с учетом того, что я все тяжелое вынес на хоум уже, включая портажи.. А есть без LVM надежый способ изменить размер, чтобы все не хренакнулось? Опыт есть?

Хм. Согласен, mdadm проработаннее. Часто в общем-то связку mdadm и LVM используют.

Это я понял, спасибо.

Я не вижу твою разметку, не могу сказать, тут от ситуации зависит. И что у тебя столько сожрало?

А ведь ты прав, да.

Накатил виртуалку на раздел диска, и все.

на уже размеченом диске?

Да. Я сразу размечаю с учетом этого.

calculate release # lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0    30G  0 part /
└─sda2   8:2    0   800G  0 part /home/dock
                                 /home
                                 /var/calculate
zram0  251:0    0  62.4G  0 disk [SWAP]
calculate release # 

calculate release # du -sh /* 2>/dev/null | sort -hr
535G    /home
16G     /var
13G     /usr
3.4G    /opt
2.1G    /lib
1.1G    /tmp
894M    /root
724M    /boot

Оба раздела ext4. В основном вон это юзер. Оси всетаки больше 10 лет. Установлена в ноябре 2011 года.

Их проще держать отдельно как минимум для того, чтобы можно было за мгновение узнать сколько они сожрали, через df, а так же ограничить их жор размером раздела (чтобы снапофлатпаки не испортили доступность места в корне для важных системных нужд - сами уткнутся в disk full, сами пострадают, зато /var/log как минимум будет на месте, а так же проги которые обновляют файлы без пересоздания копий с переименованием не получат шанс их затереть). А так же для того, чтобы когда ты поймёшь что снап не нужен - не ждать долго rm -Rf, а просто очистить раздел mkfs.

Без размеров /var/calculate непонятно, лучше бы df вместо lsblk сделал.

А то 16+13+3.4+2.1+1.1+0.9+0.7 явно превышает 30 гигов корневого раздела.

Ну не на каждый чих, просто планировать разумно. Но в целом да - стесняться поставить ещё один диск (или ещё один комп) не надо.

calculate release # df 
Файловая система 1K-блоков Использовано  Доступно Использовано% Cмонтировано в
devtmpfs             10240            0     10240            0% /dev
shm               16356112         4500  16351612            1% /dev/shm
tmpfs             16356112         2296  16353816            1% /run
/dev/sda1         30785444     23345936   5850260           80% /
/dev/sda2        824556440    572254140 210342876           74% /var/calculate
tmpfs             16777216      1090624  15686592            7% /tmp
tmpfs             16777216            0  16777216            0% /var/tmp
tmpfs             16777216      1947488  14829728           12% /var/tmp/portage
tmpfs             16777216            0  16777216            0% /var/calculate/tmp/portage
tmpfs              3271220           76   3271144            1% /run/user/1000
tmpfs              3271220            0   3271220            0% /run/user/13
calculate release # 

--- /var 
  545.7 GiB [##########################] /calculate                                                                                                                                      
    1.9 GiB [                          ] /tmp
    1.1 GiB [                          ] /db
  725.0 MiB [                          ] /log
  149.3 MiB [                          ] /cache
  118.9 MiB [                          ] /lib
   43.9 MiB [                          ] /spool
   24.0 KiB [                          ] /bind
   20.0 KiB [                          ] /svc.d
    4.0 KiB [                          ] /state
e   4.0 KiB [                          ] /opt
e   4.0 KiB [                          ] /nullmailer
    4.0 KiB [                          ] /empty
@   0.0   B [                          ]  lock
@   0.0   B [                          ]  mail
@   0.0   B [                          ]  run
calculate release # cat /etc/fstab 
# / was on /dev/sda1 during installation
UUID=3cde81e7-fdc4-4c43-b2aa-a660807da5b8       /       ext4    defaults,relatime,discard       0 1
# /var/calculate was on /dev/sda2 during installation
UUID=bc78fe03-f6d6-420f-805c-0c1ad2d2fe70       /var/calculate  ext4    defaults,relatime,discard       0 0
/var/calculate/home     /home   none    bind    0 0

# Mins  Hours  Days   Months  Day of the week   Command
tmpfs           /tmp            tmpfs           size=16G,noatime        0 0
tmpfs           /var/tmp        tmpfs           size=16G,noatime         0 0
tmpfs /var/tmp/portage tmpfs rw,nosuid,noatime,nodev,size=16G,mode=775,uid=portage,gid=portage,x-mount.mkdir=775 0 0
tmpfs /var/calculate/tmp/portage tmpfs rw,nosuid,noatime,nodev,size=16G,mode=775,uid=portage,gid=portage,x-mount.mkdir=775 0 0

proc            /proc           proc    defaults                0 0
shm             /dev/shm        tmpfs   nodev,nosuid,noexec     0 0
calculate release # 

Мне вот просто непонятно какого хрена так много сожрали бинарники в /usr и таки есть ли инструменты расширения разделом. Изменения размеров. Рабочие.

Я уже линкую на второй раздел давно что могу. Надо что то «тяжелое поставить» (ту же андроид студию) - нужен линк на второй раздел. Потому размеры и не сходятся - там куча линков.

Странно почему du на /var писал 16G хотя в него подмонтировано намного больше. Флаг -x то ты не указывал.

Мне вот просто непонятно какого хрена так много сожрали бинарники в /usr

Сделай du -h -x -t 100M /usr

Да. Я сразу размечаю с учетом этого.

с учётом чего? Что через 7 месяцев тебе понадобится поднять 3 гостевые машины под отработку чего-то? Хрена ты провидец.

calculate release # du -h -x -t 100M /usr
207M    /usr/libexec/gcc/x86_64-pc-linux-gnu/15
207M    /usr/libexec/gcc/x86_64-pc-linux-gnu
207M    /usr/libexec/gcc
637M    /usr/libexec
316M    /usr/lib/python3.12/site-packages
366M    /usr/lib/python3.12
185M    /usr/lib/wine-vanilla-11.0/wine/x86_64-windows
181M    /usr/lib/wine-vanilla-11.0/wine/i386-windows
406M    /usr/lib/wine-vanilla-11.0/wine
408M    /usr/lib/wine-vanilla-11.0
104M    /usr/lib/gcc/x86_64-pc-linux-gnu/15
104M    /usr/lib/gcc/x86_64-pc-linux-gnu
104M    /usr/lib/gcc
424M    /usr/lib/python3.13/site-packages
474M    /usr/lib/python3.13
282M    /usr/lib/llvm/21/lib
272M    /usr/lib/llvm/21/lib64
179M    /usr/lib/llvm/21/bin
805M    /usr/lib/llvm/21
805M    /usr/lib/llvm
3.0G    /usr/lib
185M    /usr/include/boost
639M    /usr/include
173M    /usr/share/doc
254M    /usr/share/icons
171M    /usr/share/mythes
125M    /usr/share/hunspell
105M    /usr/share/gir-1.0
127M    /usr/share/tessdata
102M    /usr/share/wallpapers
130M    /usr/share/man
202M    /usr/share/wine/mono/wine-mono-10.4.1/lib/mono
224M    /usr/share/wine/mono/wine-mono-10.4.1/lib
234M    /usr/share/wine/mono/wine-mono-10.4.1
234M    /usr/share/wine/mono
104M    /usr/share/wine/gecko/wine-gecko-2.47.4-x86_64
105M    /usr/share/wine/gecko/wine-gecko-2.47.4-x86
208M    /usr/share/wine/gecko
441M    /usr/share/wine
110M    /usr/share/fonts/noto
188M    /usr/share/fonts
745M    /usr/share/locale
225M    /usr/share/calculate-sources/6.18.9/boot
225M    /usr/share/calculate-sources/6.18.9
226M    /usr/share/calculate-sources/6.18.26/boot
226M    /usr/share/calculate-sources/6.18.26
450M    /usr/share/calculate-sources
130M    /usr/share/help
4.2G    /usr/share
115M    /usr/src/linux-6.18.26-calculate
115M    /usr/src/linux-6.18.9-calculate
230M    /usr/src
200M    /usr/lib64/qt6
120M    /usr/lib64/virtualbox
2.5G    /usr/lib64
1.1G    /usr/bin
13G     /usr
calculate release # 

Хм.. Я тут подумал - а ведь у меня около 100гб неразмеченного места на ссд. Если сделать рут там и перенести туда просто.

На lvm можно просто взять и перенести. Если не понравилось - перенести обратно. Без перезагрузок. Но вообще в 2026 корень надо держать на SSD, тут и думать нечего.

Но в целом да - стесняться поставить ещё один диск (или ещё один комп) не надо.

Если они у тебя так легко появляются, поделись пожалуйста материнкой под LGA 1151… оч. нужна сейчас :)

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

Всего 15 лет назад и 10-15гб хватало. Сейчас 30гб не хватает под рут. А что будет еще лет через 10-15?

Всего 15 лет назад и 10-15гб хватало.

10 лет назад у вас был hdd с 10-15 Гб под корень.

Сейчас 30гб не хватает под рут.

сейчас у вас SSD с 30Гб под рут.

А что будет еще лет через 10-15?

какой-нибудь MRAM диск с актуальным размером под корень, не?

А не хватало места как тогда, так и сейчас, и потом не будет хватать, вот посмотрим.

Как лучше поступить?

Поставить на виртуалку. Понравится - втащишь на хост.

Насколько актуален LVM на десктопе в наше время?

Смысл стремиться к нулю. Нужен очень экзотический юзкейс на десктопе, при котором стоило бы использовать lvm вместо mdadm или btrfs/zfs. Если возникает вопрос нужен он тебе или нет, то 100% не нужен.

Не уверен, что даже опцию в установщиках для десктопов предлагать - хорошая идея. Тупо захламляет интерфейс и путает новичков.

lvm не используют вместо mdadm

lvm не используют вместо mdadm

Я видел всякое дерьмо.

За 20 лет использования Линукса на десктопе возможности lvm пригодились 0 раз

Я не использую. Смысла для себя не вижу. У меня разбивка максимально простая: один SSD, три раздела: /efi, /, swap.

Если ты планируешь до переустановки ОС добавлять жёсткие диски, это может быть удобно. Если ты хочешь один раздел расположить на двух дисках, это может быть удобно. Ничего серверно-специфичного в LVM нет, технология зрелая и рабочая. Нужны её фичи - используй.

Можно, но рулить LV удобнее, чем обычными разделами.

Например, у тебя 3 раздела по 20 гигов в начале диска, и 100 гигов свободно в конце.

Если речь о виртуалках, то нет, там всё гораздо проще. У тебя не 3 раздела и зачем-то свободные 100 гб, а три диска по 20. Надо увеличить первый, увеличиваешь диск. Надо добавить еще раздел - добавляешь диск. Я даже диски не размечаю, так удобнее, увеличил диск и сразу resizefs. На десктопе же проще просто большой / сделать.

Однажды, я сделал lvm+ext4 раздел. И пришло время изменить его размер, и оказалось что сначала меняем размер lvm, потом размер ext4.

Вопрос: так размер ext4 раздела можно и без использования lvm слоя поменять (или я что-то не так вычитал в гайдах?)

Вопрос: так размер ext4 раздела можно и без использования lvm слоя поменять (или я что-то не так вычитал в гайдах?)

У тебя есть раздел, а есть файловая система на нём. Если размер раздела позволяет, то размер ext4 можно увеличить через resizefs, вопрос в том, как увеличить размер раздела.

А это зависит от ситуации. Если у тебя за разделом свободное пространство, то можно удалить существующий раздел (аккуратно) и пересоздать с той же точки с большим размером. А затем resizefs. С lvm же у тебя логические разделы и свободное пространство, последовательность значения не имеет и манипуляции с размером этих логических разделов производится штатными для lvm средствами.