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

39

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

Конкретный случай, который я видел, был в качестве эфемерного тома данных для сервера, пересекающего числа, загрузочный и корневой тома были традиционными разделами на другом устройстве хранения. -

filesystems partition lvm

— sysadmin1138
источник

Oracle VM тоже делает это - для «локального хранилища».

— Нильс

3

Я пропустил этот вопрос и начал новый, который охватывает ту же тему: unix.stackexchange.com/q/52389/4801 . Этот вопрос сейчас закрыт, но некоторые ответы там могут также быть полезными для читателей этого Q, и могут быть объединены здесь.

— dubiousjim

1

... и еще один на unix.stackexchange.com/questions/206141/…

— Дероберт

Работает, но приводит к проблемам, которые приведут к потере времени, как показано здесь - access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… .

— SLM

24

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

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

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

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

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

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

— Жиль "ТАК - перестань быть злым"
источник

2

Путаница, ахой! Мой внутренний счетчик в настоящее время склоняется к "ошибочной попытке оптимизации".

— sysadmin1138

6

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

— Ким

3

Наткнулся этот суперпользователь Q & A , который имеет несколько примеров хороших , используя hexdumpи odкоторые показывают в очень конкретных терминах , что происходит с /dev/sdaпротив .. /dev/sda1установки.

— slm

4

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

— Псуси

2

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

— Грэм Николлс

18

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

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

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools

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

— jlliagre
источник

Хорошо знать. В этом конкретном случае это было в облаке! поэтому хранилище довольно сильно абстрагируется от времени, когда дело доходит до настройки системы.

— sysadmin1138

1

Какое отношение имеет кэш записи диска к тому, используется ли таблица разделов?

— psusi

3

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

— jlliagre

4

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

— июля

1

@psusi Будет ли fsync очищать кэш диска или нет, зависит от файловой системы.

— Jlliagre

16

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

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

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

— Ник гаспарович
источник

Хорошая точка зрения! С виртуальными дисками (поскольку вы можете создавать, удалять и изменять их размер по мере необходимости) разделы кажутся бесполезным уровнем.

— Пабук

11

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

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

если вы все равно хотите использовать все пространство, вам не нужно тратить время на инструмент для разбиения
вам не нужно беспокоиться о несовместимости «стандартного» формата разделов (кстати, какой формат разделов является стандартом, DOS, BSD?), например, формат разделов DOS допускает использование только разделов размером до 2 ТБ при использовании 512 байт логических секторов!
Вам не нужно беспокоиться о проблемах выравнивания, вызванных разделением, на дисках с (в настоящее время) необычными размерами секторов (например, 4 КБ) - конечно, в текущих дистрибутивах должны поставляться инструменты разделения, которые действительно корректируют выравнивание с различными размерами секторов

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

— maxschlepzig
источник

2

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

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

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

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

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

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

— lloesche
источник