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

неразмеченный

Если на диски не планируется ставить систему(а точнее загрузчик), то таблицу разделов создавать там не нужно

Я бы разметил.
Подключая такой диск к др. системе всегда будет ясно, что не нём.

Оба по 1тб

Единицы измерения в СИ, JEDEC, или маркетинговые?

RAID

При замене - поиск диска нужного размера.

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

Если понадобится часть освободить от lvm, то удобнее сделать кучу разделов

«Если понадобится часть освободить от lvm», то делается lvresize и pvresize (последнее умеет даже gparted) с созданием раздела на освободившемся месте (я надеюсь, в 2025 никто в своём уме диски не будет размечать в MBR).

я на своих делаю gpt с единственным разделом. экономия на отсутствии разделов всё равно мизерная.

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

Может получиться так, что какая-то системная утилита посчитает диск не занятым и незаметно предложит создать там таблицу разделов, убив данные.

При замене - поиск диска нужного размера.

Это с железным RAID такие проблемы, а не с LVM. И про софтварныый mdadm можно забыть, т.к. LVM сам управляет этим. Только надо проследить, что метаданные LVM дублируются по нескольким PV и в бекап. Ну и не надо использовать сразу всё место, хотя даже так наверняка, то не всем же LV нужна избыточность?

А грузится он откуда будет?

sdb, sdc намекают на sda

pvresize не умеет двигать экстенты (а перемещение через pvmove нетривиально)
недавно обсуждалось в этой теме:
уменьшить раздел с lvm (комментарий)

я считаю это лишним. но допустимо оба варианта. чаще делают с разделом.

Если это физический диск, который не планируется увеличивать, то делай раздел. Иначе не делай.

то делается lvresize и pvresize (последнее умеет даже gparted) с созданием раздела на освободившемся месте

Если ты сделаешь pvcreate /dev/sda вместо pvcreate /dev/sda1 - то хрен тебе а не создание раздела “на освободившемся месте”.

Только надо проследить, что метаданные LVM дублируются по нескольким PV

Они по умолчанию на всех PV.

именно поэтому ОПу и советуют создать таблицу разделов. но с одним разделом, а не «кучей мелких».

а зачем ему «двигать экстенты», если lvresize их освободит? ну и да, при необходимости pvmove, но ничего «нетривиального» там нет, достаточно прочитать ман, там всё написано, даже с примерами.

При замене - поиск диска нужного размера.

Нафига? Это же бубль-гум LVM!
Если я не ошибаюсь, то на 2-х дисках будут синхронизироваться только logical volume. То есть, если сделать 200 и 300 мегабайт, то только это пространство и будет в зеркале (в случае с mirror 1). При таком раскладе можно заменить диск ёмкостью 1тб на 2тб, вернуть его в строй и всё прекрасно будет работать, а в случае замены второго 1тб на тоже 2тб и при всех выполненных операциях по увеличению, мы получим уже полноценный LVM RAID 1 ёмкостью 2тб

Если не сделать разметку, то ты сэкономишь целый один сектор (512 байт) в случае MBR и 64 сектора (32 кб) в случае GPT. Конечно, если не предполагается использовать диски как-то ещё, разметку можно не делать.

а зачем ему «двигать экстенты», если lvresize их освободит?

lvresize совершенно не обязательно освободит именно те экстенты, которые нужны для изменения размера PV.

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

В теме, на которую я сослался ранее, уже было высказано предложение написать «тривиальный» pvmove для ситуации ТС.

В чем недостатки многих мелких PV разделов? Потеря места на метаданных?

• Если это железный комп (не виртуалка) и железные диски, то создавать PV без партиции нет смысла. Более того, если ты случайно загрузишь винду, она может предложить их инициализировать. или не предложить :)

• наоборот, если это виртуалка и виртуальные диски, то нет никакого смысла делать лишнюю прослойку в виде партиции

Единицы измерения в СИ, JEDEC, или маркетинговые?

Емкость жестких дисков всегда измерялась в десятичных единицах. В отличие от оперативной памяти - та в двоичных

Всегда. Начиная с первых жестких дисков

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

Согласно Принципу Наименьшего Удивления, разметку и раздел лучше сделать.

Более того, если ты случайно загрузишь винду, она может предложить их инициализировать. или не предложить :)

В токсичном ЛОР’овском сообществе, мне кажется ты один из немногих, кто даёт адекватные и компетентные ответы.

При замене - поиск диска нужного размера.

Найдёшь два 1тб диска одинаковой целевой аудитории (т.е. не sata vs sas), которые хотя бы на байт отличаются по размеру?

Емкость жестких дисков всегда измерялась в десятичных единицах.

Встречал диски разного размера: ~930 гибибайт, ~950 гибибайт. Даже диски одного производителя различаются (на несколько мегабайт).

Ни один диск не был ровно 1тб = 10^12 байт.

Пока режу по 900 Гибибайт.

Я в шоке (на самом деле нет) от фантастических предположений

какая-то системная утилита посчитает диск не занятым и незаметно предложит создать там таблицу разделов, убив данные.

Это точно о линуксе?

если ты случайно загрузишь винду

Это точно о линуксе?

В теме, на которую я сослался ранее, уже было высказано предложение написать «тривиальный» pvmove для ситуации ТС.

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

В чем недостатки многих мелких PV разделов?

умножение сущностей без необходимости. разбираться с тем, что где лежит на «многих мелких разделах» гораздо сложней чем ОДИН раз прочитать ман. и сильно чревато ошибками.

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

что и требовалось доказать. С тривиальной задачей в Job не отправят ;-)

Может получиться
какая-то
посчитает
незаметно предложит

Чей-то слишком много для одного предложения.

Предполагаю, что анон про диски одинакового размера 1Тб -> 1Тб но разных моделей.

1Тб -> 1Тб но разных моделей.

Если RAID не предполагает замену (сломанного) диска, то это не RAID.

Ну я собстно об этом же.

кому-то и cp в консоли набрать - задача нетривиальная. что не означает, что кто-то ему должен делать это бесплатно.

Если RAID программный а тем более на LVM то пофигу что за диски.

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

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

Например, если диск размером 1.6GB, никто не заморачивался, что там реально 1536Мб. Для более мелких дисков и подавно.

А вот как пошли большие диски под сотню гигабайт, так началось :)

Я бы LVM для RAID отдал уже шифрованные блочные устройства. LUKS сделал бы с заглавиями на sda, а на sdb, sdc ещё рандомный отступ с рандомом. Заглавия с sda надо бекапить.

Соответственно LUKS отдаются целые не размеченные sdb, sdc предварительно полностью забитые рандом.

Я смотрю тебе есть что скрывать 🤨

Сегодня прятать надо все от всех. Кто его знает у кого этот диск будет завтра.

И да, по советам с этого треда надо вести для себя список серийников дисков и где они были. А то и сам потом не догадаешся в каком рейде какой диск был, придется каждое заглавие перебирать, чтобы расшифровать. С этой же целью в имена файлов отдельных заглавий LUKS стоит включать серийник диска.

я надеюсь, в 2025 никто в своём уме диски не будет размечать в MBR

А почему собственно? Вполне стандартный и общепринятый способ. Других дисков(и флэшек) практически и не вижу.

а зачем ему «двигать экстенты»

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

Если не сделать разметку, то ты сэкономишь целый один сектор (512 байт) в случае MBR

Вообще-то больше так как обычно раздел не в следующем секторе после MBR начинается,там может быть и несколько килобайтов пустых. Вот например у меня на этом компе инсталлятор Дебиана-11 создал раздел начиная с 2048 сектора. Умолчание у него такое было.

Command (m for help): p
Disk /dev/sda: 119.24 GiB, 128035676160 bytes, 250069680 sectors
Disk model: QUMO SSD        
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5d7ab183

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048 241917951 241915904 115.4G 83 Linux
/dev/sda2       241919998 250068991   8148994   3.9G  5 Extended
/dev/sda5       241920000 250068991   8148992   3.9G 82 Linux swap / Solaris

Хотя конечно при нынешних объемах дисков - не критично.

Именно 1тб не сравнивал,а так раньше когда приходилось много с железом возиться неоднократно сталкивался с тем что у разных производителей диски слегка разного размера. Начиная с 40 _мега_байтных в начале 90х.

Форточку!

Я в шоке

И напрасно.

Это точно о линуксе?

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

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

Вообще-то наборот. В те времена места хронически не хватало и если покупатель обнаруживал что его надули на несколько десятков мегабайтов то это было поводом для ругани с магазином. Попробовали бы мне в начале 90х продать 39 мегабайтов вместо 40. Особенно учитывая сколько тогда эти 40 мегов стоили.

Раньше да, было такое. А вот найти 100гб+ разные уже не уверен что получится.

Сегодня прятать надо все от всех.

Вот тут употребляется правильное слово - прятать. А шифрованный раздел на самом видном месте как раз наоборот привлекает внимание. Если уж надо что-то именно спрятать то создаем большой файл,называем его как-нибудь безобидно типа porno.avi и делаем шифрованный раздел внутри него. Это если данных которые надо прятать - не слишком много. Потому что можно налететь на проблемы с файлами размером больше четырех гигабайтов. Ну и всякие нестандартные способы разметки диска можно применять. Так,чтобы при простом подключении к обычным виндам,а искать будут из них скорее всего,показывалось оглавление с чем-то безобидным(реально читаться этому не обязательно).
А настоящие данные были доступны только с хитрыми опциями монтирования(обычно offset) под линуксом.