На йеху Москвы - основатель Parallels и Acronis

>> на серверах есть рейды, а lvm катит только как замена рейду нулевого уровня.

Не надо путать тёплое с мягким. LVM позволит проделать едва ли не любую возможную реорганизацию дисковой подсистемы, включая смену физических носителей, _без даунтайма_ вообще. А для замены RAID его никто в здравом уме использовать не будет.

Не надоело гнать тупняк? Иди лучше потыкай мышкой в KDE :)

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

то есть на десктопе, особенно с единственным винтом, lvm не нужен? А я о чем говорил?

>то есть на десктопе, особенно с единственным винтом, lvm не нужен? А я о чем говорил?

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

> Не надо путать тёплое с мягким. LVM позволит проделать едва ли не любую возможную реорганизацию дисковой подсистемы, включая смену физических носителей, _без даунтайма_ вообще.

Если винт приплыл - даунтайм будет и с LVM и без него. Просто концепция разделения по разделам не прижилась на десктопах (10 лет назад на каждом никс-ресурсе ежедневно звучал один и тот-же вопрос «столько отдать под /чегонибудь»). Вот LVM и появился - режь пили сколько влезет (о восстановлении уже как бы непопулярно думать). А на серверах LVM вхер не впился - без апаратных райдов их практически нет, или есть но с расчётом на SAN по оптике. Так-что LVM это всего лишь костыль для недочитавших man mount

>> то есть на десктопе, особенно с единственным винтом, lvm не нужен?

Мне нужен. Хотя у меня более одного HDD, а десктоп может выполнять недесктопные функции. Остальным я LVM не навязываю, но обычно рекомендую.

А что, не умеет? Вроде в GParted можно подвигать раздел. Но на практике не помню, делал ли.

> то есть на десктопе, особенно с единственным винтом, lvm не нужен?

Если предпочитаете пользоваться утилитой partition.magic.8.0.no-serial.zver.exe для изменения конфигурации разделов, запуская её на ночь, то lvm не нужен.

а зачем менять кофигурацию разделов если с практической точки зрения lvm на весь винт равнозначен разделу на весь винт?

>> А на серверах LVM вхер не впился - без апаратных райдов их практически нет

Реши задачу. Дано: RAID любого уровня на контроллере #1, другой RAID (допустим, другого уровня и большего размера) на контроллере #2. Задача: перенести все данные (динамические, изменяющиеся непрерывно) с первого массива на второй (потому что у первого что-то с контроллером, а также не хватает объёма дисков) без остановки сервисов, при этом LVM отсутствует.

Также можешь поделиться своими откровениями здесь: [RAID1] [XXI век, блджад] Перенос существующей системы без cp -ax

Я двигал в своё время. Давно было. По-моему, отгрызал от помойки на ext3 в пользу рейзера.
Вроде нормально прошло. Относительно небыстро, конечно, но без потерь.

> при этом LVM отсутствует.

Это задача из разряда СЗЗБ. FS надо было выбирать для сервисов соответствующую.

>> FS надо было выбирать для сервисов соответствующую.

Например? Кстати, к переносу корня системы это тоже относится? Но это уже риторический вопрос :)

> Например

ZFS.

Кстати, к переносу корня системы это тоже относится?

Да.

>> ZFS.

Это не просто ФС, а как раз аналог LVM. Поэтому и получится.

Горшочек, не вари!

Передача закончилась уже.

> Это не просто ФС, а как раз аналог LVM.

Если долго мучаться что нибудь получится. Только архитектурный подход в LVM как к кластерной прослойке между физикой и фс мне не нравится. И конструкция zpool/zfs как-бы пограмотней и шустрее. Но на вкус и на цвет - фломастеры разные.

Если разбить весь винт на один раздел результат будет абсолютно аналогичен а одним слоем абстракции будет меньше.

И потерять всю ФС в случае сбоя десятка-другого блоков, огрести кучу проблем при потенциальной миграции? Спасибо, не надо.

то есть на десктопе, особенно с единственным винтом, lvm не нужен?

Это ты не нужен. Купил новый винт, хочешь переехать на него /home, твои действия без LVM? С LVM всё просто -> pvmove /dev/grp/home /dev/sdb2, и всё. А без оного?

>И потерять всю ФС в случае сбоя десятка-другого блоков,

в случае lvm риск сохраняется

>А без оного?

Гружусь в однопользовательском режиме, переношу на новый раздел с сохранением прав. Редактирую fstab. Не каждый же день новый винт покупаешь

в случае lvm риск сохраняется

В случае с LVM на каждую операцию есть бэкап метаданных LVM (это штатное поведение юзерспейсных утилит lvm), и восстановить метаданные можно за несколько минут.

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

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

Серьезный минус LVM имеет только для дуалбутчиков. Вот для них - да, LVM это проблема.

>В случае с LVM на каждую операцию есть бэкап метаданных LVM

можно подумать что в любой журналируемой фс этого нет. Зачем нужно городить ФС поверх ФС никто так и не ответил.

> с надежностью и технологичностью разбиения стораджа на разделы.

так где эта надежность и технологичность? Все преимущества разбивки диска на разделы сводятся на нет

так где эта надежность и технологичность?

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

можно подумать что в любой журналируемой фс этого нет

В «любой журналируемой ФС» при наличии бэда в районе расположения журнала, ФС херится с завидным качеством.

>В «любой журналируемой ФС» при наличии бэда в районе расположения журнала, ФС херится с завидным качеством.

А если бэд попадет в метаданные lvm?

распиленную по разделам систему труднне привести в неработоспособное состояние.Т

если над разделами нет лишних слоев абстракции

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

А если бэд попадет в метаданные lvm?

То он ремапнется, а метаданные восстановятся из бэкапа.

а если не восстановятся?

А с чего им не восстановиться? Бэкап - это текстовый файлик, лежащий на другом разделе, в другом конце диска

Так по условию диск сыпется же

> Так по условию диск сыпется же

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

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