С блоками, зарезервированными, Ваши пользователи и сервисы, которые работают как определенные пользователи вместо того, чтобы работать как корень, не могут заполнить filesystsem и потенциально повредить другие вещи, которые должны записать в упомянутую файловую систему - хотя сервисы, работающие как корень все еще, могут все еще сделать это абсолютно полным, конечно.
Это также дает Вам некоторое пространство для работы с тем, когда пользователи жалуются, что диск полон, или сервисы начинают перестать работать, потому что файловая система полна. Например, Вы могли заархивировать некоторые файлы прочь в архивы zip/gz/7zip прежде, чем удалить их (хотя, если файловая система была абсолютно полна, возможности - Вы, имеют некоторую другую файловую систему, доступную, в котором Вы могли создать архивный файл вместо этого).
5% были значением по умолчанию в течение долгого времени от спины, когда диски были намного меньшими (десятки мегабайтов скорее затем сотни гигабайтов), таким образом, 5% не были всем так очень. К счастью это может легко быть настроено вниз на меньший процент, как Вы говорите или устанавливаете на определенное количество блоков, если Вы используете tune2fs
-r
опция вместо -m
. В обоих случаях можно дать параметр 0 для выключения резервирования полностью - я не сделал бы этого для /
, /tmp
, /var
и т.д, но Вы могли бы хотеть для файловой системы, которая только действует как пользовательское устройство хранения данных (скажите, что глобальная доля файла) или та, которая просто содержит файлы фиксированного размера (как фиксированный измерил VMs), который только вырастет, когда Вы создадите новый.
Pro: Вы не тратите впустую один сектор диска на таблицу разделов. (Yay).
Pro: диск может использоваться в операционной системе, которая не поддерживает разделы стиля ПК. (Как Вы собираетесь использовать тот.)
Довод "против": это необычно и может смутить co-системных-администраторов. (См.?)
Довод "против": при установке другой операционной системы она могла бы думать, что диск содержит мусор, и помогите случайно перезаписать ее путем выбора неправильного диска — тогда как операционные системы обычно оставляют в покое разделы, тип которых они не понимают.
Не важный: расширение файловой системы не легче, если это находится непосредственно на диске, чем если бы это находится в разделе, ни наоборот. (Быть на LVM помогло бы.)
Заключение: это работает, но это не хорошая идея.
Не уверенный в то, как это относилось бы к Linux, но с собственным ZFS, одна причина, рекомендуется создать пулы на целых дисках и не разделах, находится в бывшем случае, который может быть включен кэш записи на диск.
Несколько других причин также упоминаются здесь:
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools
Заключение: это работает и могло бы быть хорошей идеей в зависимости от файловой системы.
Я вижу реальную выгоду, когда это сделано в виртуальной среде. Начиная с нашего VMDK's хранятся на нашем NAS, мы можем вырастить их динамично.
Если мы используем разделы, любой, который мы должны использовать LVM (и издержки, связанные с ним), и объединить разделы в цепочку вместе, или мы должны удалить хост (или файловая система если не используемый) для использования чего-то как gparted.
Однако при использовании целого диска вместо раздела можно вызвать пересканирование на дисках SCSI и использовать resize2fs для роста файловой системы, в то время как это онлайн (и используемый!).
Размещение файловой системы на дисковом устройстве, не создавая раздела не состоит в том что редко.
Преимущества:
Способность изменить размер файловой системы на неструктурированном устройстве не является серьезным основанием. Пространство Вы сохраняете тот путь, Вы не можете использовать для других вещей. Таким образом можно просто непосредственно создать файловую систему на целом устройстве.
Ответ, который не был указан в списке: если вы не создаете раздел, вам не нужно ждать, пока ядро обнаружит его, может быть только после перезагрузки.
Одним из вариантов использования может быть том EC2 EBS, который вы добавляете к узлу и хотите инициализировать при первой загрузке.
Если ваш процесс инициализации создает раздел, вы рискуете перезагрузиться, чтобы ядро увидело вновь созданный раздел. Обычно вы видите сообщение вроде:
Ошибка: Ошибка информирования ядра об изменениях в разделе / dev / xvde1 - Устройство или ресурс занят. Это означает, что Linux не будет знать ни о каких изменениях, внесенных вами в / dev / xvde1, пока вы не перезагрузитесь, поэтому вам не следует монтировать его или использовать каким-либо образом перед перезагрузкой.
В этом случае ваш процесс инициализации должен будет выполнить перезагрузку, а затем продолжить добавление файловой системы к вновь созданному разделу.
Если вы знаете, что вам понадобится только один раздел, вы можете пропустить его, чтобы избежать риска перезагрузки.
hexdump
иod
которые показывают в очень конкретных терминах, что продолжает a/dev/sda
по сравнению с./dev/sda1
установка. – slm♦ 04.05.2013, 05:10