Comments 67
Кстати, жизнь в новых линуксах с разделами стала проще, потому что теперь partition table системного диска может обновляться без перезагрузки.
Почему всё-таки GPT а не LVM? Потому что LVM слишком сложен. GPT прост, и это его большое преимущество, для стандарта, который должны понимать все ОС и понимать совершенно одинаково.
Мечтаю, видимо.
Когда RedHat начнет выпускать прошивки или железо — вот тогда они смогут пропихнуть что-угодно в свои продукты, а пока их ОС ставится на сервера и рабочие станции Lenovo, Dell или HP, их безопасники за одну только идею добавить в прошивку еще один весьма нетривиальный парсер на С любому голову оторвут.
Вы действительно хотите поддержку снапшотов у mirror volumes в EFI? Зачем оно винде, например, которая LVM не использует, а поддерживать будет вынуждена?
Стандарты должны быть разумными. Это включает в себя минимальное пересечение по требованиям для интероперабельности.
LVM в этот стандарт никак не укладывается. С тем же успехом можно требовать поддержки btrfs в качестве EFI тома или linux raid 60 для загрузки.
GPT без MBR не работает, точнее не существует. (Может я просто не видел что GPT существовал целиком на диске с сектора 0, а не с сектора 1.)
это вписано в основы GPT и весьма правильно.
псевдозапись MBR
Хмм… Псевдозапись значит.
440 байт продолжают использоваться по назначению(Для BootCode), а разделы в MBR(4 в стандарте, но зависит от типа MBR(! Для дискстора вроде можно и 8 держать на диске)) можно писать как писали до GPT(4 GPT таблиц на диске держать можно, но толку 0.).
От GPT диск не шифруется! И MBR не шифрует GPT. А просто указывает на наличие GPT разметки в разделе.
От случайного удаления или перезаписи может спасти только Backup 0-33 сектора на внешний носитель.
случайного удаления програмками
Вижу это как главный козырь? (Даже GPT не защищает от DD и программ автоматической перезаписи данных.)
У Apple своя же разметка вроде, разве нет? (Задумался.)
Однако разделы в общем это нормальная практика.
И в этом плане MBR проработан достаточно сильно.
Ненужна куча разделов, просто нужны нужные разделы и их типы. (4(Boot, Swap, RootFS, Home) достаточно(Но как я упоминал ранее есть для большего количества Diskstore.))
А вот то что нужна динамика в изменении разделов, ну я понимаю что это упрощение, но я бы сказал что это сильное излишество.
Нет, подождите. Опять создай раздел? Может быть кто-нибудь догадается в спецификацию 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 может быть опасно. Если есть хотя бы небольшой шанс случайного подключения этого диска к Windows-компьютеру неквалифицированным пользователем — лучше не надо, от данных могут остаться только оправдания «Да он же пустой был!». (Думаю, это одна из причин, почему GPT-разметка диска имитирует наличие MBR.)
Но минуточку, для системных администраторов, где уже все давно виртуализировано, это обычно нонсенс. Нужно просто загружать систему с минимальной болью.
Ну так загрузите Grub по сети. В этой ситуации отдельный загрузчик на диске просто не нужен — можно хоть LVM, хоть LVM поверх LUKS, хоть Btrfs.
Зачем на компе с 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.
А root уже можно монтировать в lvm:
<img src=«А не проще добавить небольшой диск под boot изначально, раз речь об виртуальных серверах и теоретически возникнет проблема с последующим расширением раздела(хотя опять же в таком случае проще добавить диск в vg расширении имхо)? А root уже можно монтировать в lvm:
Зачем вообще разделы нужны? Раньше файловые системы не могли адресовать весь обьем диска, теперь вроде бы таких проблем нет.
Имхо это просто следование глупым традициям, никаких реальных проблем наличие разделов не решает.
1. Ограничение размера (квоты не везде работают нормально).
2. Возможность использования разных ФС
3. Возможность использования разных опций монтирования (особенно касательно журнала)
4. Не поверите, чтобы ограничить раздел и увеличить скорость random read/write
В самих разделах нет ничего страшного и ужасного, но автора сильно печалит невозможность увелисения размера разделов (в некоторых случаях)
- ??? Это проблема мбр, что где то у кого то квоты не работают?
Единственный правильный на мой вкус способ "разбиения на разделы" это операционка на одном диске, пользовательские данные на другом диске. Если операционок больше двух, то запихиваем их в виртуальные машины.
Можно бесконечно придумывать разные искуственные юзеркейсы, зачем нам кровь из носу нужны разделы, но все они не имеют отношения к главной теме статьи. Нам зачем то нужна куча разделов с постоянной возможностью менять их размер.
Анек в тему.
Поиходит мужик к врачу…
- Доктор, когда, я делаю вот так, у меня болит вот здесь.
- А вы "вот так" не делайте.
… и что люди только не придумают, лишь бы не использовать zfs...
Я могу сделать консистентный (относительно) снэпшот с rootfs и его забекапить.
Просто снэпшоты, как по мне, не должны быть функционалом файловой системы.
Если хотите избавиться в этом предложении от слова «относительно», придётся выносить снэпшоты на уровень файловой системы. Если вы при этом хотите иметь качественные компрессию, дедупликацию и шифрование, то придётся встраивать в ФС и их тоже. В результате продвинутая ФС неизбежно получается сложной.
ряд приложений могут открывать что-то с флагом O_DIRECT
Используя O_DIRECT, корректно написанное приложение должны быть готово обломаться.
EINVAL The filesystem does not support the O_DIRECT flag.
See NOTES for more information.
Строго говоря, O_DIRECT ничего никому не обещает: ФС может просто проигнорировать этот флаг и работать как обычно.
См. https://unix.stackexchange.com/q/238794/
Но я простой пользователь, а тут разговор на уровне не ниже сисадмина… Пока всё это с вашего уровня спустится на наш, много воды утечёт.
/dev/sda1 есть /boot на 500МБ (предполагаю тот самый MBR)
/dev/sda2/ есть LVM на всё остальное дисковое пространтсво.
Что в этом полхого? Фактически LVM почти на всём диске. Дели нарезай разделы как хочешь.
Почему это?
Я с LVM дел не имел, но судя по вашему описанию он умеет расширяться в добавленное пространство. Увеличиваете размер раздела, в котором он настроен (если раздел в конце диска), даёте команду LVM'у расшириться в появившееся дополнительное место, и всё.
Поэтому я и говорю, что разделы — зло, если уже есть LVM.
Так а в чём проблема то? Ну мелкое дополнительное действие. Тогда можно сказать и что система выделения места на хостинге плохая — вам надо сначала увеличить "диск" а потом только увеличивать LVM. А вот если бы диск сам увеличивался при попытке записи за границу его размера — было бы проще.
Это проблема его поддержки конкретным софтом, а не самого формата. Если не привязываться к конкретному софту, то увеличение раздела в MBR делается правкой 4 байтов в загрузочном секторе. Возможно ptmax так и делает.
Знаете, как на 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, он классный и много чего умеет, в том числе двигать и ресайзить разделы без потери данных.
И да, до 16.04 sfdisk надо было для загрузки вызывать с ключом -f.
Но еще раз, по факту, это удаление разделов и создание их заново. А не обновление 4 байтов.
Если есть возможность — лучше воспользуйтесь gparted, он классный и много чего умеет, в том числе двигать и ресайзить разделы без потери данных.
Только не переносите на объем меньше переносимого раздела в сторону(либо по оффсэту) или фигакс данным.
Отдаем весь диск btrfs и GRUB прекрасно ставится в зарезервированный 1М (в начале диска перед фактическим началом потрохов btrfs). И в таком режиме все прекрасно грузится (там, вроде как, MBR c таблицей разделов невольно возникает при установке GRUB, но не используется)
Никаких тебе таблиц разделов — все в шоколаде…
… только вот SWAP (если нужен) испортит эту лебединую песню т.к. пока его без костыльного велосипеда с loop девайсом не создать в btrfs…
Безусловно, на RedHat свет клином не сошелся, но все же.
Но упоминать красную шапку с их древним ядром, как повод для беспокойства в судьбе btrfs — еще более не серьезно… они просто уже не могут продолжать тянуть обновления связанные с btrfs в свое древнее ядро… уж слишком сильно оно отстало от мейнстрима… Вот когда (если) они хотя бы на 4.4 перейдут, и при этом не захотят поддерживать btrfs — вот тогда буде повод задуматься…
LVM + lilo > GPT + EFI (или почему GRUB такой неуклюжий)