Преимущества файловой системы без разделов

Пару недель назад я столкнулся с чем-то, чего раньше не видел: файловая система (думаю, это была ext3), установленная на устройство хранения без раздела. По сути, /dev/sdb была всей файловой системой. Я знаю, что многие файловые системы могут расширяться в пустое пространство, и такое использование позволяет расширяться без необходимости работы с LVM или другим видом менеджера томов, но есть ли какие-то другие преимущества настройки хранения таким образом?

В конкретном случае, который я наблюдал, это был временный том данных для сервера числовых вычислений, загрузочные и корневые тома были традиционными разделами на совершенно другом устройстве хранения. –

Плюс: вы не теряете один сектор диска на таблицу разделов. (Ура.)

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

Минус: это необычно и может запутать других системных администраторов. (Видите?)

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

Не важно: расширение файловой системы не проще, если она находится непосредственно на диске, чем если она в разделе, и наоборот. (На LVM это было бы проще.)

Вывод: это работает, но это не самая хорошая идея.

Я вижу реальное преимущество, когда это делается в виртуальной среде. Поскольку наши VMDK хранятся на нашем NAS, мы можем динамически их увеличивать.

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

Однако, если вы используете весь диск вместо раздела, вы можете принудительно сделать повторное сканирование на ваших SCSI-дисках и использовать resize2fs, чтобы увеличить файловую систему, пока она находится онлайн (и используется!).

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

Несколько других причин также упомянуто здесь: ZFS Best Practices

Вывод: это работает и может быть хорошей идеей в зависимости от файловой системы.

Размещение файловой системы на устройстве диска без создания разделов не так уж и необычно.

Преимущества:

• когда вы хотите использовать все пространство, вам не нужно тратить время на работу с инструментом разделения
• вам не нужно беспокоиться о несовместимости ‘стандартного’ формата разделов (кстати, какой формат разделов является стандартом, DOS или BSD?), например, формат DOS позволяет создавать разделы только до 2 ТБ, если используются логические сектора размером 512 байт!
• вам не нужно беспокоиться об ошибках выравнивания, вызванных разделами, на дисках с (в настоящее время) необычными размерами секторов (напр., 4 кб) – конечно, текущие дистрибутивы должны поставляться с инструментами разделения, которые работают правильно с разными размерами секторов

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

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

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

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

Ошибка: Ошибка информирования ядра о модификациях раздела /dev/xvde1 — Устройство или ресурс заняты. Это означает, что Linux не узнает о любых изменениях, которые вы внесли в /dev/xvde1, до перезагрузки — так что его не следует монтировать или использовать каким-либо образом до перезагрузки.

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

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

Я думаю, что это рутина, но для USB-накопителей это становится неудобством. По крайней мере, в Linux.

Если после монтирования USB-накопителя без разделов вы размонтируете “раздел”, диск, похоже, полностью отсоединяется. То есть для повторного монтирования вам нужно физически вынуть и вставить USB-накопитель заново.

Небольшой аспект, который кажется отсутствующим в обсуждении:

Коротко: диски (HDD или SSD) без разделов не работают с системами Microsoft. По крайней мере, Windows 10 твердо отказывается признавать файловую систему с диска без разделов, утверждая, что он “неинициализированный”.

Я использовал диски без разделов для архивных целей в течение довольно долгого времени по той простой причине, что в какой-то момент диски стали превышать MBR, и fdisk на моем компьютере не мог создавать GPT-разделы, и я не утруждался разбираться, как создавать GPT-разделы с помощью инструмента gpt. Все было нормально, пока мне не пришлось поделиться таким диском с человеком, который использует Windows.

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq ясно утверждает, что “суперфлоппи” допускается только для съемных носителей. HDD в USB-доке по их мнению не являются съемными. Так что это не баг, это фича.