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

эмм двигая в gparted ползунки я как раз размер раздела и меняю же, или не?

эмм двигая в gparted ползунки я как раз размер раздела и меняю же, или не?

Наверно, не использовал. Я сам процесс под капотом описал:

Уменьшаешь размер fs, удаляешь существующий раздел и на его месте с того же места создаёшь раздел меньшего раздела.

Либо удаляешь существующий раздел и создаёшь большего размера, а потом изменяешь размер fs.

эмм двигая в gparted ползунки я как раз размер раздела и меняю же, или не?

Да, там в выполненных действиях можно увидеть, что он менял раздел и запускал resize2fs

Ну раз тебе это так легко, отсыпь с барского плеча мне 256 гигабайт DDR5 и NVMe SSD на 4 терабайта ;-)

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

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

Уху. А размещённые на диске данные начинают движение от этого действия?

Какая связь между оперативной памятью и LVM?

Ты сам про новый ПК написал.

Но да, речь о HDD и SSD, которые с конца 25 года сильно подорожали.

Нисколько. Разве что тебе заняться нечем — тогда возникает это вот непреодолимое желание засунуть лвм в бтрфс, как у местных капитанов рейда, чтоб потом решать проблемы, которых у них без этого не было. «Не было забот, завели порося». Смысла нет даже у «просыпаться по утрам», только ты сам можешь придать этому какой-то смысл.

Я не про «новый ПК» писал, а про то, что для отличающихся задач желательно иметь отдельные вычислительные устройства. То, что LVM оказывается ненужно - это побочный эффект.

Подорожавшие SSD/HDD - не повод кроить гигабайты.

С зеркалами такого не было никогда. Вот с кэшированными томами - да (по крайней мере на моей системе), нужно обязательно деактивировать том на инитлевеле 0 или 6, иначе при следующей загрузке будет пересинхронизация. Но, возможно, это какой-то косяк моей конфигурации.

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

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

Чтобы сразу было понятно, чего они стоят.

Работая с физ. разделами тебе нужно учитывать как размер, так и взаимное расположение. Перемещение соседних разделов это нетривиальная и относительно тяжелая (длительная) операция. К тому же изменение начала раздела может привести к проблемам, если он загрузочный (в multiboot сценариях).
В случае же логических разделов нет требования, чтобы свободное место было одним непрерывным куском.

Что касается изменения размера ФС на логическом разделе, то здесь все точно также как на физическом. LVM тут преимуществ не дает.

Есть ли смысл попробовать LVM

Попробовать есть смысл. Чтобы понять, почему он не нужен.

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

С риском потерять данные? Можно.

Удобно делать операции с разделами на живую. Если не планируется делать какие-то перестановки с дисками (например на минипк я накатываю одним разделом всё), то нет смысла. На десктопе я всегда делаю LVM теперь.

Лично для меня (а я занимаюсь разработкой для облаков и сторадже) лвм крайне полезен потому что даёт возможность создавать сырые тома для виртуалок с производительностью близкой к производительности дисков, без оверхеда ФС без плясок с разделами. Если мне не нужна производительность то использую тонкие диск в qcow, если просто shared device - то sparse raw, если производительность честная нужна - беру лвм. Ну и да, миграция дисков становится удобной в многодисковом конфиге

В проде активно использовали lvm с mirror/raid1 томами. Данных не теряли даже в жёстких авария с глюками железа и отвалами pci

А можно через zfs без риска.

Я её и вне контекста LVM пишу. Выкраивать какие-то копейки это всегда порочный путь. Если у тебя кончается место - ты этими выкраиваниями только чуть отсрочишь конец, потом всё равно придётся покупать новый накопитель. Зато, в ходе выкраиваний, превратишь простую, тривиальную структуру хранения в опасную кашу.

В случаях, когда твои расходы на хранение данных реально велики, речь про разделы вообще не идёт - там уже наоборот: думаешь сколько дисков выделить под ту или иную задачу, а инкремент размера хранения соответственно делается уже 8-16+ ТБ приращениями, ни о каких гигабайтах думать не надо.

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

Мы всё ещё про десктоп? Имхо это бессмысленное усложнение себе жизни: побить диск на кучу разделов, а потом вкрячить доп прослойку, чтобы от этого разбиения не зависеть. Вполне по-русски: создать себе проблемы, чтобы потом героически их решать.

Какую ещё доп. прослойку? Я как раз предлагаю использовать разбиение по разделам для лучшего учёта и ограничения занятого места.

От закончившегося /tmp не должны портиться логи, от закончившегося места в логах - не должно блокироваться создание файлов в корне, от снапа сожравшего свой раздел - не должно ломаться ничего кроме снапа.

Сабжевую. А если без неё, то разделы тем более не нужны. На практике один геморрой.

Эм, где это я LVM предлагал делать? Я наоборот.

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

усложнение

А фс это не усложнение? Какая фс была на перфокартах? Давайте к ним вернёмся. Да что уж. И сам ПК - усложнение. Есть же счёты, бумажка с ручкой, пальцы.

поставить ещё один диск

Особенно легко это сделать в ноутбуках. Или не рассматриваем их как десктоп?

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

А, понятно. Но не сталкивался с ситуацией на десктопе, когда скорость работы с диском у vm перевешивало бы удобство файлов.

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

btrfs сам по себе - адекватный дефлот для десктопа и нужно обосновать еще использование чего-то другого.

Я просто размечаю все диски на десктопах по принципу: раздел под efi, раздел под boot, корень (с btrfs). Разделы под boot/efi много места не отъедают, но их наличие экономит время при потенциальных перестановках дисков. А btrfs - самый простой способ получить сжатие+рефлинки+снапшоты, плюс возможность объединить диски в один большой «раздел» и в любом момент их разобрать.

Я один раз разметил диск при покупке и даже при любых изменениях конфигурации дисков и перестановках к разделам больше не прикасаюсь.

В случае же LVM гость получает практически прямой доступ к блочному устройству.

Любой гость? Или только линуксы?

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

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

Сейчас в связи с внедрением btrfs LVM уже не особо актуален.

Ну тут вопрос такой, есть ли доверие к btrfs или нет. Если не особо, то LVM + ext4 – норм тема.

pvmove как раз умеет двигать с указанием экстентов или политикой

или lvextend --alloc contiguous

А какая разница какой гость? Гипервизору дают блочное устройство снаружи - он его показывает внутри.

Другое дело, что этот «прямой доступ» мало чем отличается от просто аккуратно размещённого (без фрагментации) файла на разделе. Файловая система весьма мало оверхеда добавляет, и подозреваю большая его часть случается при открытии файла (которое один раз в начале).

Какое удивительное открытие! Оказывается, чтобы в 10-литровое ведро налить 20 литров, то надо сначала заменить ведро!!! *ужас мрак кошмар памагити*

я тебя не услышал

Thin provisioning оказался неудобен - нельзя уменьшить, а при сбоях питания он долго пересобирается.

Ну-ка с этого момента поподробнее, я тут обратил внимание что Шапка по умолчанию с 9ки стала пихать это дело. Не думаю что там все на самом деле так плохо…

P.S. Что касается btrfs то ее можно использовать только на ssd, у нее скорость по отношению к ext4 и xfs раз в 5 меньше.

Скорость не может быть больше или меньше. Меньше или больше может быть значение. Скорость может быть выше или ниже.

Ваш полковник.

Извините я думал на форуме люди сидят а не ИИ и понимают смысл.

https://www.phoronix.com/review/linux-70-filesystems

Ору)))

Это можно делать в пределах одного PV, чтобы выровнять?

В мане есть такое:

If the source and destination are on the same disk, the anywhere allocation policy is needed.

pvmove --alloc anywhere /dev/sdb1:1000-1999 /dev/sdb1:0-999

Да я не копал особо. У меня были несколько томов на терабайтном пуле и после нештатного выключения система стартовала полчаса, сидя на монтировании тех самых томов. Это было не само монтирование, и даже не fsck, а потроха lvm, что, впрочем, трудно понять, глядя лишь на дефолтный загрузочный лог, но systemd-analyze раскрыл мне глаза. Кажется, ещё мне пришлось увеличить таймаут монтирования где-то в юнитах systemd или в fstab, а то оно вываливалось в rescue (но это я проделал давно и могу что-то напутать или конфигурация по умолчанию могла быть с тех пор изменена на более разумную).

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

Существуют даже дефрагментаторы для LVM. С т.з. производительности нужды в них нет, но иногда непрерывный lv - это приятно глазу.

Иногда бывает нужно. Например, VM-level backup не сможет исключить swap из бэкапа, если он фрагментирован.

Что касается btrfs то ее можно использовать только на ssd, у нее скорость по отношению к ext4 и xfs раз в 5 меньше.

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

Btrfs отлично подходит для hdd, а за счет сжатия порой даже быстрее выходит. Где-то на форуме приводил сравнение влияния fs на hdd на разделе для сборки исходников (gentoo), ext4 стабильно и ощутимо негативно влиял на скорость сборки на фоне xfs/btrfs (неожиданный результат был для меня). У меня на всех домашних hdd под данные btrfs (> 100 tb дисков), даже диски под торренты перевел с xfs, так как много времени занимает периодическая проверка целостности торрент-клиентом и эффективнее переложить это на плечи fs.

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

Как будто торент клиент видит что там за фс и не делает проверку …

Насчет 5 я загнул, но там есть график по ПГ посмотрите на него и это вам по круче сборки генты.

Кстати на сборку в гентоо больше влияет цпу и рама, если фс там задействована так сильно тут что не то.

Как будто торент клиент видит что там за фс и не делает проверку …

Не делает, её надо делать вручную. Когда у тебя десятки ТБ это чрезвычайно медленный процесс.

Насчет 5 я загнул, но там есть график по ПГ посмотрите на него и это вам по круче сборки генты.

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

При этом, если не нужно выжимать максимальную скорость, то btrfs/zfs хороша для пострегса, так как позволяет получить полноценное сжатие в его бесплатной версии (что чаще всего ценнее). Там где TimescaleDB не подходит я использую zfs с постгресом. Просто 600 Гб базы превращаются в 200 Гб.

Кстати на сборку в гентоо больше влияет цпу и рама, если фс там задействована так сильно тут что не то.

Это был тест практической разницы меду фс на задаче, для которой btrfs интуитивно плохо подходит, а по факту оказалось, что хуже всего в ней ведет себя ext4 с ощутимой разницей. Когда речь о размещении документов, фоточек, видео, игрушек на десктопе, то с btrfs может конкурировать в плане практичности только zfs, и то с нюансами.

Это был тест практической разницы меду фс на задаче, для которой btrfs интуитивно плохо подходит, а по факту оказалось, что хуже всего в ней ведет себя ext4 с ощутимой разницей. Когда речь о размещении документов, фоточек, видео, игрушек на десктопе, то с btrfs может конкурировать в плане практичности только zfs, и то с нюансами.

Ну вам виднее. Я так сильно с btrfs не занимался, просто мне не нравится ее ограничения что снимки нельзя на cow размещать и т.д.

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