Достоинства файловой системы без раздела

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

Это также дает Вам некоторое пространство для работы с тем, когда пользователи жалуются, что диск полон, или сервисы начинают перестать работать, потому что файловая система полна. Например, Вы могли заархивировать некоторые файлы прочь в архивы zip/gz/7zip прежде, чем удалить их (хотя, если файловая система была абсолютно полна, возможности - Вы, имеют некоторую другую файловую систему, доступную, в котором Вы могли создать архивный файл вместо этого).

5% были значением по умолчанию в течение долгого времени от спины, когда диски были намного меньшими (десятки мегабайтов скорее затем сотни гигабайтов), таким образом, 5% не были всем так очень. К счастью это может легко быть настроено вниз на меньший процент, как Вы говорите или устанавливаете на определенное количество блоков, если Вы используете tune2fs -r опция вместо -m. В обоих случаях можно дать параметр 0 для выключения резервирования полностью - я не сделал бы этого для /, /tmp, /var и т.д, но Вы могли бы хотеть для файловой системы, которая только действует как пользовательское устройство хранения данных (скажите, что глобальная доля файла) или та, которая просто содержит файлы фиксированного размера (как фиксированный измерил VMs), который только вырастет, когда Вы создадите новый.

39
29.05.2011, 21:45
5 ответов

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

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

Довод "против": это необычно и может смутить co-системных-администраторов. (См.?)

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

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

Заключение: это работает, но это не хорошая идея.

24
27.01.2020, 19:35
  • 1
    , на палубе! Мой внутренний метр в настоящее время склоняется "к дезинформированной попытке оптимизации". –  sysadmin1138 30.05.2011, 02:35
  • 2
    другой довод "против": мешает позже разделять раздел на два. –  Kim 30.05.2011, 06:40
  • 3
    Столкнулся с этим суперпользователем Вопросы и ответы, который имеет некоторое хорошее использование в качестве примера hexdump и od которые показывают в очень конкретных терминах, что продолжает a /dev/sda по сравнению с. /dev/sda1 установка. –  slm♦ 04.05.2013, 05:10
  • 4
    , немного более просто расширить объем на целом диске, так как Вы не должны сначала расширять раздел. –  psusi 20.01.2014, 06:35

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

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

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

Заключение: это работает и могло бы быть хорошей идеей в зависимости от файловой системы.

18
27.01.2020, 19:35
  • 1
    Хороший для знания. В этом конкретном случае это было в облаке! таким образом, устройство хранения данных довольно в большой степени абстрагировано к тому времени, когда оно приходит к системной установке. –  sysadmin1138 30.05.2011, 14:25
  • 2
    К чему же, спрашивается, имеет отношение кэш записи на диск, используется ли таблица разделов? –  psusi 30.05.2011, 18:06
  • 3
    Кэш записи не может быть включен на уровне раздела. При включении это влияет на диск в целом. Если файловая система использует целый диск, она "владеет" тем диском, таким образом, она может включить и выключить тот кэш без любого сопутствующего риска. Иначе выполнение его могло бы влиять на другого дискового потребителя, нуждающегося в том кэше, который будет отключен по его собственным причинам. –  jlliagre 31.05.2011, 00:37
  • 4
    Несомненно, но наличие ОС, ослепляюще включающей кэш, не зная файловую систему или потребительские требования неструктурированного устройства, не является надежным подходом. Существуют приложения как базы данных, которые должны быть уверены, что зафиксированная транзакция находится на диске и не только в памяти. –  jlliagre 01.06.2011, 19:22
  • 5
    @psusi, Сбросит ли fsync дисковый кэш или не надеется быть зависимым файловой системы. –  jlliagre 20.01.2014, 14:37

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

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

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

16
27.01.2020, 19:35
  • 1
    ! С виртуальными дисками (поскольку можно создать, удалите и измените размер их по мере необходимости), разделы, кажется, бесполезный слой. –  pabouk 12.05.2017, 11:14

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

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

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

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

11
27.01.2020, 19:35

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

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

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

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

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

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

3
20.08.2021, 13:35

Теги

Похожие вопросы