LINUX.ORG.RU

Таблицы разделов на больших дисках — как обойтись без GPT?


1

1

В общем, всё в топике.

Мне не нравится GPT, поскольку оно связано с UEFI, поддерживается шиндошс, хоть и плохо и тд, но большие жесткие диски рано или поздно будут у каждого линуксоида.

Вот я и хочу у дорогого Коллективного Разума уточнить, а есть ли другие способы разбиения жесткого диска кроме GPT, с которых может загружаться GNU/Linux и BSD, но не MS-DOS (вроде как на размере диска больше какого-то около пары терабайт LBA уже не канает), желательно ещё и не поддерживаемый распространёнными проприетарными ОС, но работающий и для OpenBSD и для GNU/Linux и желательно для других полноценных ОС?

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

А если ничего кроме GPT, уже работающего нет, может быть всем ЛОРом скооперируемся и разработаем новый стандарт разбиения жестких дисков на разделы, желательно такой стандарт, который был бы легко понятен для редактирования вручную, был бы лёгок для реализации на ассемблере, но при этом не страдал ограничениями на количество и тип разделов?

За основу можно взять например LVM и BSD disklabel.

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

Перемещено tazhate из talks

P.S. Стандарт придуман:

Берём классическую схему MS-DOS, в ней первый байт 16-байтной записи используется как признак «активности раздела». Теперь это будет флаговый байт, в который мы добавим ещё два флага:

0x00 — Раздел данных, целеком помещающийся в первые 2 тебибайта диска, использующий 512-битные сектора
0x40 — Раздел данных, использующий 512-битные сектора, где байты CHS используются как старшие байты LBA
0x60 — Раздел данных, использующий 4096-битные сектора, где байты CHS используются как старшие байты LBA
0x80 — корневой раздел ОС, целеком помещающийся в первые 2 тебибайта диска, использующий 512-битные сектора
0xC0 — корневой раздел ОС, использующий 512-битные сектора, где байты CHS используются как старшие байты LBA
0xE0 — корневой раздел ОС, использующий 4096-битные сектора, где байты CHS используются как старшие байты LBA.

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

При этом получается, что раздел не может быть длинней чем 2^68 байт при размере сектора 4 килобайта, это 256 эксбибайт, этого должно хватить лет на 20, а потом можно таки ввести новую схему или просто просто повысить размер одного сектора например до мегабайта, при этом будет задействованы остальные биты флагового байта, тогда размер поднимется до 64 зебибайт

★★★★★

Последнее исправление: Xenius (всего исправлений: 5)

толсто

впрочем можешь вот из этого выбрать

(parted) help mklabel                                                     
  mklabel,mktable ТИП_МЕТКИ         создать новую метку диска (таблицу раздела)

	ТИП_МЕТКИ один из: aix, amiga, bsd, dvh, gpt, mac, msdos, pc98, sun,
        loop

dimon555 ★★★★★
()
Ответ на: комментарий от dimon555

MS-DOS явно отпадает, ибо не поддерживает большие диски, а об остальных кроме loop я ничего не знаю толком.

BSD как справляется с дисками более скольких-то там терабайт?

Xenius ★★★★★
() автор топика

вроде как на размере диска больше какого-то около пары терабайт LBA уже не канает

LBA не имеет прямого отношения к таблице разделов и не ограничивается «парой терабайт».

Мне не нравится GPT, поскольку оно связано с UEFI

LOL.

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

Нет.

GotF ★★★★★
()

Мне не нравится GPT, поскольку оно связано с UEFI

Просто свали, GPT нигде и никак к UEFI не привязан, кроме твоего сознания.

Lighting ★★★★★
()
Ответ на: комментарий от GotF

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

Нет.

Почему это нет? Если раздел с LVM не превышает ограничения таблицы разделов, то запросто.

Lighting ★★★★★
()

желательно ещё и не поддерживаемый распространёнными проприетарными ОС

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

Lighting ★★★★★
()

желательно ещё и не поддерживаемый распространёнными проприетарными ОС

А браузером ты тоже пользуешься только таким, который не поддерживается распространёнными проприетарными ОС?

krakatau
()
Ответ на: комментарий от GotF

Loop — не таблица разделов, это такой костыль.

Это не костыль и не таблица разделов, это один «раздел» на весь жесткий диск.

Для небольших дисков и флешек по-моему идеально.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от krakatau

А браузером ты тоже пользуешься только таким, который не поддерживается распространёнными проприетарными ОС?

Konqueror 3.5 рулит кстати, но в связи с отсутствием KDE 3 в новых дистрибутивов и тем что собирать его лень, был вынужден перейти на другие свободные браузеры.

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Lighting

Если раздел с LVM не превышает ограничения таблицы разделов, то запросто.

Речь шла о том что бы physical volume LVM было всё блочное устройство, например /dev/sda — можно ли как-то загружаться при такой конфигурации

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Lighting

GPT нигде и никак к UEFI не привязан, кроме твоего сознания.

А теперь открываем википедию и видим:

«GUID Partition Table, аббр. GPT — стандарт формата размещения таблиц разделов на физическом жестком диске. Он является частью Расширяемого микропрограммного интерфейса (англ. Extensible Firmware Interface, EFI) — стандарта, предложенного Intel на смену отжившего BIOS, одного из последних реликтов первозданной IBM PC. EFI использует GPT там, где BIOS использует Главную загрузочную запись (англ. Master Boot Record, MBR).»

Не связан с (U)EFI, говоришь?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от GotF

LBA не имеет прямого отношения к таблице разделов и не ограничивается «парой терабайт».

А LBA48?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

Это именно костыль для дебиановского установщика. То же самое, что и mkfs /dev/sdX.

GotF ★★★★★
()
Ответ на: комментарий от Lighting

Почему это нет?

Попробуй. Я пробовал.

GotF ★★★★★
()
Ответ на: комментарий от Xenius

Не читай русскоязычной Википедии перед обедом(да и после обеда тоже).

http://en.wikipedia.org/wiki/GUID_Partition_Table

It forms a part of the Extensible Firmware Interface (EFI) standard, which is Intel's proposed replacement for the PC BIOS.

Intel therefore developed a new partition-table format in the late 1990s as part of what eventually became UEFI. The GPT as of 2010 forms a subset of the UEFI specification.

А сказано там что? А сказано там то, что GPT является(теперь уже) частью стандарта, то есть, EFI использует GPT как таблицу разделов по умолчанию, не более того.

Lighting ★★★★★
()
Ответ на: комментарий от GotF

Что LBA48? 128 петабайт.

Только вот откуда взялось 48?

Вообще, я думаю что можно вполне обойтись форматом MS-DOS, во-первых CHS больше не нужно, значит можно эти три байта взять для LBA, кроме того четыре байта там и так уже есть, в сумме это получается 7 байт или 56 бит, а если размер логического блока 4 кб как на современных жестких дисках, то это получается 2^68 байт, то есть 256 эксбибайт, этого хватит ещё лет на 20, думаю, а к тому времени наверное и жесткие диски устареют.

То есть GPT не нужен, ибо это лишняя сущность.

А что бы не вводить в заблуждение ОС, не поддерживающие использование байтов CHS как старших разрядов LBA, для таких записей можно ввести например код активности, отличающийся от 00 и 80, если зарезервированные под CHS байты используется для LBA

Xenius ★★★★★
() автор топика

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

Можно, lilo сумеет загрузить с простого LV.

const86 ★★★★★
()

Таблица разделов не нужна. Создаётся ФС btrfs непосредственно на устройстве. Для разделения на разделы используется subvolumes. Ненавистные проприетарные ОС пока не поддерживают.

Deleted
()
Ответ на: комментарий от GotF

Ты не понял. LILO в данном случае будет некуда ставить.

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

const86 ★★★★★
()
Ответ на: комментарий от const86

Т.е., к примеру, делаем

pvcreate /dev/sda
vgcreate foo /dev/sda
lvcreate -n bar -l 100500G foo
# здесь установка системы на LV bar и LILO на /dev/sda #
?

У меня такое получалось, но загрузчик убился при первой операции с метаданными LVM :( Видимо, чего-то не понял я.

GotF ★★★★★
()
Ответ на: комментарий от Deleted

Создаётся ФС btrfs непосредственно на устройстве.

А груб встанет?

Xenius ★★★★★
() автор топика

FreeBSD может загрузиться с RAW-носителя с ZFS. Сам лично проверял.

iZEN ★★★★★
()
Ответ на: комментарий от GotF

У меня такое получалось, но загрузчик убился при первой операции с метаданными LVM :(

Надо проследить, кто и куда пишет лишнего. У меня lilo в первом секторе, а метаданные lvm начинаются со второго. Соответственно, при изменениях lvm пишет в свои сектора и не трогает lilo.

Такой же фокус работает с ext*, например. Можно форматнуть весь диск и поставить lilo.

const86 ★★★★★
()

может быть всем ЛОРом скооперируемся и разработаем новый стандарт разбиения жестких дисков на разделы, желательно такой стандарт, который был бы легко понятен для редактирования вручную, был бы лёгок для реализации на ассемблере, но при этом не страдал ограничениями на количество и тип разделов?

Начни. А мы подхватим. Было бы желание.

iZEN ★★★★★
()
Ответ на: комментарий от const86

метаданные lvm начинаются со второго

Да, действительно. А разве LILO влезает в 512 байт? Ему вроде надо больше, хотя и не так много, как GRUB.

Такой же фокус работает с ext*, например. Можно форматнуть весь диск и поставить lilo.

Там это предусмотрено. Можно даже GRUB2 :)

GotF ★★★★★
()
Ответ на: комментарий от const86

У меня lilo в первом секторе

А как он туда влезает? Это же 512 байт... или он догружает кусочки себя по абсолютному адресу?

Xenius ★★★★★
() автор топика
Ответ на: комментарий от iZEN

Начни. А мы подхватим. Было бы желание.

Уже начал, в конце поста черновик стандарта — взять за основу MS-DOS и расширить.

В тот же формат таблицы разделов вполне могут вписываться и жесткие диски до 256 эксабайт

Xenius ★★★★★
() автор топика

Во-первых, GPT это не изобретение форточек. на макосе оно было и есть давно.

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

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

mmarkk
()
Ответ на: комментарий от mmarkk

Во-первых, GPT это не изобретение форточек. на макосе оно было и есть давно.

Макось чем-то лучше винды?

но после pvmove будут проблемы с загрузкой.

То есть надо делать lilo после каждого изменения раздела? А GRUB или GRUB2 можно?

В третьих. чем тебе не понравился GPT

Большой оверхед, несовместимость с DOS-MBR даже на маленьких дисках.

Для сравнения — смотри мой формат в главном сообщении. Нафига городить костыль если можно просто отказаться от хранения CHS?

UEFI - это хорошо. долой 16-битный код из загрузчика

UEFI — это плохо, долой проприетарный код из загрузчика.

UEFI проприетарный, но имеет больше власти над компьютером чем классический BIOS, значит он хуже.

А если не нравится 16-битный код, давно есть CoreBoot и OpenBIOS

Xenius ★★★★★
() автор топика
Ответ на: комментарий от Xenius

Большой оверхед, несовместимость с DOS-MBR даже на маленьких дисках.

в чем состоит оверхед и зачем нужна совместимость?

Reset ★★★★★
()
Ответ на: комментарий от Xenius

Итаг. Я не понял при чём тут лило, но сделать нормальный вариант с одним жёстким диском и без таблицы разделов и со стандартным биосом по ходу нельзя.

А плюс гпт в том что он стандартизирован и можно сказать входит в спецификацию железа.

Еще мысль. Если самодельная замена биоса будет уметь читать лвм то проблема отпадет сама собой

Поэтому, не надо изобретать свою таблицу разделов. Надо либо смириться со встронным биосом или уефи. Либо заняться поддержкой лвм в коребуте или опенбиосе ( она там наверняка уже есть ).

Основная проблема в том что уефи понимает только две таблицы разделов, а биос вообще ничего не понимает. Поэтому и стали реализовывать эти недопонимания в грубе.

И ещё уефи это хорошо. Зашивание же ключа туда это плохо. И да, уефи не имет больше власти над компом. Там просто больше драйверов вшито, которые кстати линукс не использует насколько я знаю. Зато всех их можно использовать в загрузчике, и при том полностью открытом ( таком как груб) благодаря тому что интерфейс к этим драйверам открыт и стандартизирован. И даже более того. Можно добавить свой драйвер чтобы встроенное в железо уефи могло читать файлы с лвма

mmarkk
()
Ответ на: комментарий от Xenius

Маленькие диски не нужны. Дос не нужен.

На ембеддед загрузка вобще по другому устроена.

mmarkk
()

By default, the LVM label is placed in the second 512-byte sector. You can overwrite this default by placing the label on any of the first 4 sectors. This allows LVM volumes to co-exist with other users of these sectors, if necessary.

Так что у нас есть как минимум 1536 байт для стейдж один плюс стейдж два. Но этого маловато. Исследую.

mmarkk
()
Ответ на: комментарий от Xenius

Да, lilo в boot секторе хранит номер сектора map-файла (/boot/map) а в нём уже номера остальных секторов. Поэтому это файл нельзя «трогать». И там не 512 байт, а 448 байт.

mky ★★★★★
()
12 апреля 2012 г.
Ответ на: комментарий от mmarkk

Так что у нас есть как минимум 1536 байт для стейдж один плюс стейдж два. Но этого маловато. Исследую.

Вторую ступень загрузчика можно разместить как логический том LVM...

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

В принципе, парсер не сложный, надо искать последовательность «ИмяГруппы { ... logical_volumes { ... ИмяТома { ... segment1 {», после чего брать значения из полей extent_count и stripes. Думаю, уместиться в полтора килобайта возможно.

geekless ★★
()
Ответ на: комментарий от mmarkk

В каком смысле? Ты ж не собираешься перемещать том с загрузчиком на другой физический носитель, я надеюсь)

geekless ★★
()
Ответ на: комментарий от geekless

Нет не собираюсь. Просто дефрагментация лвмов. Иногда она нужна. И еще подумай про снапшоты, которые в грубе вообще не подерживаются

В принципе, если сделать маленький лвм без фс то пойдёт. Соглашусь с тобой. Будет примерно как в гпт. Т. е. Отдельно выделенный раздел для внедрения втрой стадии.

А /boot уже можно хранить вместе с корнем на одной фс. Пожалуй да. Когда писал прошлое сообщение не подумал что стейдж 2 же не обязательно в виде файла на фс делать.

mmarkk
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.