Pull to refresh

Comments 67

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

Кстати, жизнь в новых линуксах с разделами стала проще, потому что теперь partition table системного диска может обновляться без перезагрузки.

Почему всё-таки GPT а не LVM? Потому что LVM слишком сложен. GPT прост, и это его большое преимущество, для стандарта, который должны понимать все ОС и понимать совершенно одинаково.
Я всю дорогу считал, что поскольку за LVM стоит RedHat, эту спецификацию уж точно запихнут в ряд поддерживаемых в EFI. И опять же, поскольку обычно первый мегабайт свободен, никто не мешает делать GPT, который будет аналогичен раскладке томов в LVM для тех, кому это нужно.

Мечтаю, видимо.

Когда RedHat начнет выпускать прошивки или железо — вот тогда они смогут пропихнуть что-угодно в свои продукты, а пока их ОС ставится на сервера и рабочие станции Lenovo, Dell или HP, их безопасники за одну только идею добавить в прошивку еще один весьма нетривиальный парсер на С любому голову оторвут.

LVM сложен. Очень сложен. Mirror volumes, снапшоты.

Вы действительно хотите поддержку снапшотов у mirror volumes в EFI? Зачем оно винде, например, которая LVM не использует, а поддерживать будет вынуждена?

Стандарты должны быть разумными. Это включает в себя минимальное пересечение по требованиям для интероперабельности.

LVM в этот стандарт никак не укладывается. С тем же успехом можно требовать поддержки btrfs в качестве EFI тома или linux raid 60 для загрузки.

GPT без MBR не работает, точнее не существует. (Может я просто не видел что GPT существовал целиком на диске с сектора 0, а не с сектора 1.)

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

Хмм… Псевдозапись значит.
440 байт продолжают использоваться по назначению(Для BootCode), а разделы в MBR(4 в стандарте, но зависит от типа MBR(! Для дискстора вроде можно и 8 держать на диске)) можно писать как писали до GPT(4 GPT таблиц на диске держать можно, но толку 0.).


От GPT диск не шифруется! И MBR не шифрует GPT. А просто указывает на наличие GPT разметки в разделе.


От случайного удаления или перезаписи может спасти только Backup 0-33 сектора на внешний носитель.


случайного удаления програмками

Вижу это как главный козырь? (Даже GPT не защищает от DD и программ автоматической перезаписи данных.)

То, о чем Вы говорите, называется Protective MBR. Однако, оно уже все реже используется. А есть еще Hybrid, когда MBR дублирует первые 4 раздела из GPT, это Apple любит.

У Apple своя же разметка вроде, разве нет? (Задумался.)
Однако разделы в общем это нормальная практика.
И в этом плане MBR проработан достаточно сильно.
Ненужна куча разделов, просто нужны нужные разделы и их типы. (4(Boot, Swap, RootFS, Home) достаточно(Но как я упоминал ранее есть для большего количества Diskstore.))
А вот то что нужна динамика в изменении разделов, ну я понимаю что это упрощение, но я бы сказал что это сильное излишество.

В мире отличном от x86 достаточно частое явление отсутствие MBR при наличии GPT посмотрите на тот же Jetson K1/X1/X2. Если uboot или какой-либо другой первичный загрузчик ядра лежит в NOR/NAND/SPI/QSPI флешке то наличие lilo/grub противопоказано, а MBR, GPT и других disk label совершенно опционально.
Нет, подождите. Опять создай раздел? Может быть кто-нибудь догадается в спецификацию EFI добавить поддержку LVM? Пожалуйста?

Через мой труп, извините. Иметь драйверы любых файловых систем кроме совсем тривиальных в прошивке — верный способ быть взломанным через втыкание внешнего носителя с творчески испорченной ФС, разбор которой приведет к выполнению вредоносного кода в BDS, а дальше там обход SecureBoot, обход пароля от BIOS Setup, и прочее воровство и убийство.
Вот вам один стандартный формат и драйвер к нему, оба простые как палка — пользуйтесь, городите поверх них любые LVMы, ZFSы, APFSы, что угодно, а прошивке оставьте ее GPT, который просто работает.

Еще раз, пожалуйста, поймите главный message этой статьи — откажитесь от обычной таблицы разделов. Будь то MBR, будь то GPT, оно Вам не нужно, если есть LVM

Я, честно говоря, так и не понял. Разбиение диска на разделы — это же операция, которая в 99% случаев делается один раз в жизни диска. А в остальных 1% лучше её сделать на существующих костылях, чем искать универсальное решение в ущерб простоте.
Ровно до того случая, когда Вам нужно будет изменить размер разделов. Про снэпшоты и бекапы я даже не говорю.

Ну так сделайте один раздел на весь диск и на нем хоть LVM, хоть Ceph Bluestore.


LVM существенно сложнее GPT. В LVM нетривиально получить данные по логическому смещению.

Смотрите, при виртуализации часто бывает ситуация, когда Вы меняете (т.е. увеличиваете) размер диска виртуальной машины. И что тогда делать?

Хранить виртуалки на LVM или Ceph? Всегда так делаю :-)

А, я понял — вы про изменение размера диска внутри виртуалки.


Очень редко с таким сталкиваюсь, всегда проще нарезать новую, а данные на загрузочном диске и не хранятся. Я даже не уверен что облака AWS / GCP поддерживают такое.


Как это решается? примитивным скриптом. Отресайзить единственный раздел и отресайзить фс. Если на лету страшно — то ребутнуть машину, coloudinit отресайзит на загрузке.

Я такое проделывал неоднократно:
1. На хосте с Linux: lvresize -L +10G STORAGE/WIN01-C
2. В windows на виртуалке в диспетчере дисков увеличил размер тома «С:»

Более того, я также и уменьшал размер виртуального диска:
1. В windows на виртуалке в диспетчере дисков уменьшил размер тома «D:» и вывел в офлайн диск, содержащий том «D:
2. На хосте с Linux в parted посмотрел верхнюю границу раздела
3. На хосте с Linux: lvresize -L 145395711s STORAGE/WIN01-D
4. В windows на виртуалке в диспетчере дисков перевёл в онлайн диск, содержащий том „D:
Зачем мне надо будет менять размер разделов, точнее одного раздела с LVM внутри — мне нужно поменять размеры нужных мне LV? Бэкапить и снапшотить я тоже буду LV.
Вы — нет, а я, как IT-тролль, первое что сделаю, это засуну LV в качестве одного из PV вовнутрь PG. И бедный EFI должен будет deal with this.
Ну а как часто вы это делаете в обычной жизни? Мне за четверть века жизни в обнимку с компьютером это приходилось делать всего лишь несколько раз. В каждом случае я брал актуальную на то время утилитку разметки дисков и переразбивал их. Т.е. поддержка этой функции операционной системой «из коробки» практически не востребована (кроме каких-то частных и редких кейсов). По крайней мере, калории, потраченные на её установку и настройку, не окупаются.

Согласен с первым комментатором, что отдавать весь диск под LVM может быть опасно. Если есть хотя бы небольшой шанс случайного подключения этого диска к Windows-компьютеру неквалифицированным пользователем — лучше не надо, от данных могут остаться только оправдания «Да он же пустой был!». (Думаю, это одна из причин, почему GPT-разметка диска имитирует наличие MBR.)


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

Ну так загрузите Grub по сети. В этой ситуации отдельный загрузчик на диске просто не нужен — можно хоть LVM, хоть LVM поверх LUKS, хоть Btrfs.

GPT не просто имитирует MBR, она как бы может его использовать в гибридном режиме, что любит Apple. Не вижу проблемы создать Protective MBR для LVM.
Статья из разряда: придумать себе проблему и пытаться решить ее.

Зачем на компе с UEFI ставить GRUB или LILO? Это лишний загрузчик в цепи.
UEFI Boot manager прекрасно запускает EFISTUB linux kernel.
UEFI Boot manager прекрасно запускает EFISTUB linux kernel.

Прекрасно запускает с LVM-тома?


Статья из разряда: придумать себе проблему и пытаться решить ее.

Нет, статья из разрядов «железка будет делать так, как я хочу, а не так, как ей удобно» и «кажется, теперь действительно пора лечиться от перфекционизма». С точки зрения автора, MBR (или GPT) — лишняя абстракция, не нужная для его целей, поэтому он её исключил. Благо ядро Linux не имеет ничего против.

Прекрасно запускает с LVM-тома?

Со стандартного ESP раздела.
С точки зрения автора, MBR (или GPT) — лишняя абстракция, не нужная для его целей, поэтому он её исключил. Благо ядро Linux не имеет ничего против.

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

А, в таком случае нужно вооружатся EDK и писать свой EFI драйвер для LVM.
Поддерживаю. Именно так у меня почти все мои компы и грузятся — вот утилитку наваял под это дело: github.com/slytomcat/UEFI-Boot
Очень много раз меня спасала привычка делать в начале диска крохотный FAT раздел, с DOS и lilo.exe под DOS. Да, знаю толк, но возможность поднять сервак с уьитым загрузчиком по kvm — бесценна
я прям образ исошки обычно пишу. однажды помогло.
как по мне, так проще немного lvm допилить. пусть при использовании всего диска сделает что-то похожее на раздел, что будет символизировать наличие lvm на диске
А не проще добавить небольшой диск под boot изначально, раз речь об виртуальных серверах и теоретически возникнет проблема с последующим расширением раздела(хотя опять же в таком случае проще добавить диск в vg расширении имхо)?
А root уже можно монтировать в lvm:
<img src=«А не проще добавить небольшой диск под boot изначально, раз речь об виртуальных серверах и теоретически возникнет проблема с последующим расширением раздела(хотя опять же в таком случае проще добавить диск в vg расширении имхо)? А root уже можно монтировать в lvm:

была проблема LVM c systemd, которую регшал переустановкой. с тех пор LVM как то не очень

Зачем вообще разделы нужны? Раньше файловые системы не могли адресовать весь обьем диска, теперь вроде бы таких проблем нет.
Имхо это просто следование глупым традициям, никаких реальных проблем наличие разделов не решает.

Разделы нужны для 4 следующих причин:

1. Ограничение размера (квоты не везде работают нормально).
2. Возможность использования разных ФС
3. Возможность использования разных опций монтирования (особенно касательно журнала)
4. Не поверите, чтобы ограничить раздел и увеличить скорость random read/write

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


  1. ??? Это проблема мбр, что где то у кого то квоты не работают?
    Единственный правильный на мой вкус способ "разбиения на разделы" это операционка на одном диске, пользовательские данные на другом диске. Если операционок больше двух, то запихиваем их в виртуальные машины.
    Можно бесконечно придумывать разные искуственные юзеркейсы, зачем нам кровь из носу нужны разделы, но все они не имеют отношения к главной теме статьи. Нам зачем то нужна куча разделов с постоянной возможностью менять их размер.
    Анек в тему.
    Поиходит мужик к врачу…
    • Доктор, когда, я делаю вот так, у меня болит вот здесь.
    • А вы "вот так" не делайте.
LVM не только меняет разделы. Я могу сделать консистентный (относительно) снэпшот с rootfs и его забекапить. Попробуйте это на досуге с обычными разделами.

… и что люди только не придумают, лишь бы не использовать zfs...

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

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

Если хотите избавиться от слова «относительно», то придется узнать, что дело не в связке «раздел -> фс», а в том, что ряд приложений (не будем показывать пальцем) могут открывать что-то с флагом O_DIRECT, тогда фс вообще без понятия, что там происходит.
ряд приложений могут открывать что-то с флагом O_DIRECT

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


man 2 open
EINVAL The filesystem does not support the O_DIRECT flag.
       See NOTES for more information.

Строго говоря, O_DIRECT ничего никому не обещает: ФС может просто проигнорировать этот флаг и работать как обычно.
См. https://unix.stackexchange.com/q/238794/

Так в том и дело, что мы с Вами пришли к соглашению — неважно, где мы делаем снапшот, приложение есть проблема. Но еще раз, я готов долго холиварить на тему «где лучше делать снапшот, в блочном девайсе или в файлухе», но все же пока склоняюсь к блочному девайсу.
Зачем мне нужны разделы? Да очень легко, вот крутится уэб сэрвер, на нём всякий ноты.жыэс, похапе, пёрлы и прочие с функционалом «дыра». Уэбсервер должен куда-то уметь писать всякий мусор без особых проблем. Теперь ксакеп вася берёт и заливает какой-нить бинарь, который через дыру в запускает… Ой, не вышло, у меня на /tmp noexec,nosuid, nodev и ещё куча всего стоит. Дешего и сердито, можно конечно с grsec/PaX заморочаться и настроить всё так, что ксакеп даже с дырявым пхп 5.0 и нифига сделать не сможет, но это потребует огромных время и трудозатрат, что не эффективно с точки зрения Убитых Енотов.
Ой, не вышло, у меня на /tmp noexec,nosuid, nodev и ещё куча всего стоит.

Ничего не мешает примонтировать LVM-том с опциями noexec, nosuid и nodev, MBR или GPT для этого не обязательны.

С MBR не всё так просто… Дело в том, что под него наработана куча удобных простому пользователю инструментов и методик, и отказаться от всего этого ему нелегко. Гляньте на содержимое известного пакета ремонтно-восстановительных утилит 2k10 — там для восстановления загрузки есть с десяток программ, но… для MBR. Эквиваленты всего этого для UEFI до меня пока не докатились.
Но я простой пользователь, а тут разговор на уровне не ниже сисадмина… Пока всё это с вашего уровня спустится на наш, много воды утечёт.
Для восстановления UEFI тоже уже есть инструменты: boot-repair например.
Немного не догоняю. Поясните — сейчас сделал lsblk на CentOS7.
/dev/sda1 есть /boot на 500МБ (предполагаю тот самый MBR)
/dev/sda2/ есть LVM на всё остальное дисковое пространтсво.

Что в этом полхого? Фактически LVM почти на всём диске. Дели нарезай разделы как хочешь.
А теперь попробуйте увеличить размер диска — это запросто бывает в виртуализированных средах. Тогда чтобы отдать добавленный «хвост» в LVM надо будет создать еще один раздел, его тоже пихнуть в LVM. Проделайте это еще два раза и выяснится, что теперь надо делать extended partition. Ну и поехали.
Можно создать отдельный образ, в котором будет LVM поверх сырого диска, и уже его наращивать.
Так обычно и делается, только зачем два диска? На одном держать загрузочную часть для EFI? Можно, но только две сущности вместо одной.

На диске, где LVM поверх сырого, свободен первый мегабайт. Так почему бы и нет?

Почему это?
Я с LVM дел не имел, но судя по вашему описанию он умеет расширяться в добавленное пространство. Увеличиваете размер раздела, в котором он настроен (если раздел в конце диска), даёте команду LVM'у расшириться в появившееся дополнительное место, и всё.

У Вас LVM в разделе. Тогда надо сначала увеличить раздел, а потом уже увеличивать LVM.

Поэтому я и говорю, что разделы — зло, если уже есть LVM.

Так а в чём проблема то? Ну мелкое дополнительное действие. Тогда можно сказать и что система выделения места на хостинге плохая — вам надо сначала увеличить "диск" а потом только увеличивать LVM. А вот если бы диск сам увеличивался при попытке записи за границу его размера — было бы проще.

Знаете, как на MBR увеличиваются разделы? Удаляете и создаете новый. Не самая веселая операция. См. выше про утилиту ptmax для этой цели.

Это проблема его поддержки конкретным софтом, а не самого формата. Если не привязываться к конкретному софту, то увеличение раздела в MBR делается правкой 4 байтов в загрузочном секторе. Возможно ptmax так и делает.

В таком духе все проблемы в IT мире в софте, а не в формате, конечно.
Знаете, как на MBR увеличиваются разделы? Удаляете и создаете новый.

Вас кто-то дезынформировал. Для того, чтобы увеличить размер последнего на диске primary-раздела, достаточно заменить одни три байта на другие три байта — sfdisk с этим прекрасно справляется.


К сожалению, у меня нет MBR-раздела под рукой, чтобы продемонстрировать, но для GPT это тоже работает. Нужно как-то так:


Шаг 1. Сдампим текущую таблицу разделов в файл.


# sfdisk --dump /dev/sda | tee partitions.txt
label: gpt
label-id: <...>
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 500118157

/dev/sda1 : start=        2048, size=      262144, <...>
/dev/sda2 : start=      264192, size=      784384, <...>
/dev/sda3 : start=     1048576, size=   249020416, <...>
/dev/sda4 : start=   250071040, size=   250046464, <...>

Шаг 2. Залезем в сдампленный файл редактором. В последней строчке заменим size=250046464 на size=*.


Шаг 3. Скормим дамп обратно.


# sfdisk /dev/sda <partitions.txt

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

Да без проблем, можно и sfdisk, только я вообще рассматриваю с точки зрения fdisk.

И да, до 16.04 sfdisk надо было для загрузки вызывать с ключом -f.

Но еще раз, по факту, это удаление разделов и создание их заново. А не обновление 4 байтов.
Но еще раз, по факту, это удаление разделов и создание их заново. А не обновление 4 байтов.

На диске обновится пара десятков секторов (в случае с GPT). Данным при этом не будет ничего — лишь бы в новой таблице смещения разделов совпали с теми, что было в старой (а они совпадут, никуда не денутся).

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

Только не переносите на объем меньше переносимого раздела в сторону(либо по оффсэту) или фигакс данным.

LVM — отстой. :) Подтома btrfs — наше все. :)

Отдаем весь диск btrfs и GRUB прекрасно ставится в зарезервированный 1М (в начале диска перед фактическим началом потрохов btrfs). И в таком режиме все прекрасно грузится (там, вроде как, MBR c таблицей разделов невольно возникает при установке GRUB, но не используется)
Никаких тебе таблиц разделов — все в шоколаде…

… только вот SWAP (если нужен) испортит эту лебединую песню т.к. пока его без костыльного велосипеда с loop девайсом не создать в btrfs…
У меня есть серьезные основания сомневаться в будущем btrfs против LVM лишь потому, что RedHat теперь считает ее deprecated.

Безусловно, на RedHat свет клином не сошелся, но все же.
Ну вы же понимаете, что я не слишком серьезно все это упомянул…

Но упоминать красную шапку с их древним ядром, как повод для беспокойства в судьбе btrfs — еще более не серьезно… они просто уже не могут продолжать тянуть обновления связанные с btrfs в свое древнее ядро… уж слишком сильно оно отстало от мейнстрима… Вот когда (если) они хотя бы на 4.4 перейдут, и при этом не захотят поддерживать btrfs — вот тогда буде повод задуматься…
Sign up to leave a comment.

Articles