Я часто задавался вопросом, почему существует такая страсть к разделению дисков, особенно в ОС Unixy (/ usr, / var, et al). Это не похоже на общую тему с установками Windows.
Кажется, что разделение значительно увеличивает вероятность заполнения одного раздела, в то время как другие имеют много свободного места. Очевидно, что это может быть предотвращено тщательным проектированием и планированием, но все может измениться. Я сталкивался с этим на компьютерах много раз, в основном на тех, которые были настроены другими, или с настройками установки по умолчанию для рассматриваемой ОС.
Еще один аргумент, который я слышал, это то, что он упрощает резервное копирование. Как это упрощает резервное копирование? Я также слышал, что это повышает надежность. Опять как?
Почти 100% проблем, с которыми я столкнулся с дисковым хранилищем, связано с физическим отказом диска. Можно ли утверждать, что разбиение диска может потенциально ускорить сбой оборудования из-за перегрузки диска при перемещении или копировании данных из одного раздела в другой на том же диске?
Я не пытаюсь раскачивать лодку слишком сильно, я просто хотел бы увидеть оправдание для давней админской практики.
Ответы:
Я не думаю, что установка большого количества разделов - это то, что вы должны делать для каждой системы. Лично на большинстве Linux моих серверов я просто настраивал один большой раздел. Так как большинство моих систем имеют небольшие диски и имеют одно назначение и выполняют некоторые функции инфраструктуры (dns, dhcp, firewall, router и т. Д.). На моих файловых серверах я делаю разделы настройки, чтобы отделить данные от системы.
Я очень сомневаюсь, что хорошо разделенная система будет иметь большую вероятность отказа.
источник
Одна из причин оставить / home / seperate в том, что вы можете переустановить операционную систему и не беспокоиться о потере пользовательских данных. Кроме того, при монтировании всего, что доступно только для чтения, или noexec, необходимо обеспечить большую безопасность. Если пользователи не могут запустить код где-либо, где они могут написать код, это на один вектор атаки меньше.
Однако я бы побеспокоился об этом только на общедоступной машине, поскольку недостаток дискового пространства в одном разделе, а наличие его в другом - это серьезное раздражение. Есть способы обойти это, например, программный рейд или ZFS, где вы сможете легко динамически изменять размеры разделов, но у меня нет опыта работы с ними.
источник
Вы можете делать резервные копии (с помощью dumpfs или подобного) из того, что вы хотите, а не из того, что вы не делаете. dump (1) - лучшая система резервного копирования, чем tar (1).
Это также аргумент в пользу разделения. Пользователи, заполняющие свои домашние каталоги, не разрушают сервер, не отключают веб-сервер, не допускают появления журналов, не позволяют войти в систему и т. Д.
Это также позволяет вам более прозрачно переместить часть ваших данных (скажем, / home) на другой диск: скопировать его, смонтировать. Если вы используете что-то, что позволяет теневые копии / снимки / что угодно, вы даже можете сделать это вживую.
источник
Меня всегда учили хранить / var на отдельном разделе, поэтому, если вы получите файл журнала из-под контроля, вы засорете один раздел, а не весь диск. Если он находится в том же пространстве, что и остальная часть системы, и вы на 100% заполняете весь диск, он может выйти из строя и привести к неприятному восстановлению.
источник
Все аргументы, выдвигаемые Zoredache, являются действительными; кто-то может немного поспорить с деталями (имея машину быстрее, чтобы вы могли делать другие вещи, в то время как fsck'инг других файловых систем не принесет вам большой пользы, если причина существования системы в первую очередь в этих других файловых системах) ; однако они все немного оправдания за фактом.
В действительно старые школьные времена у вас не было файловых систем на отдельных разделах - они были на отдельных дисках, потому что диски были очень маленькими. Подумайте 10 МБ. (1) Итак, у вас был крошечный / раздел, диск / var, диск / usr, диск / tmp и / home диск. Если вам нужно больше места, вы купили другой диск.
Тогда «большие» 50-мегабайтные диски стали стоить дешевле, чем программа «Луна», и внезапно появилась возможность разместить всю систему на одном диске с достаточным количеством пользовательского пространства.
Тем не менее, размер диска был небольшим по сравнению с тем, что мог генерировать компьютер, изолировать / var и / opt и / home, чтобы заполнение диска не приводило к выходу компьютера из строя, было все еще хорошей идеей.
Сегодня в корпоративной ситуации я не делю операционные системы. Данные разделяются, особенно если они генерируются пользователем; но часто это происходит из-за того, что это какие-то высокоскоростные и / или избыточные дисковые массивы. Однако / var и / usr находятся в одном разделе с /.
В домашней среде то же самое - / home, вероятно, должен находиться на отдельном диске / массиве, чтобы можно было устанавливать / обновлять / ломать / исправлять любые версии ОС.
Причина этого заключается в том, что независимо от того, насколько велика ваша догадка / var или / usr или какое-либо другое дерево, - вы либо будете смешно неправы, либо смехотворно преувеличены. Один из моих старых (эр) школьных коллег ругается на разделы, и я всегда испытываю от него горе, когда он заканчивает тем, что просидел через 180 дней в системе, которую я создал. Но я могу рассчитывать на одну руку за всю мою карьеру, сколько раз что-то было заполнено / разрушено системой, в то время как я могу посчитать одну руку столько раз, сколько в этом году я смотрел на систему, где кто-то решил, что / var никогда не должен был бы быть больше (скажем) 1 ГБ и ошибался, из-за чего я смотрел на полный / var и 100 свободных ГБ в других местах системы, и все это с таким же успехом могло бы быть для всех добро они мне делают.
В современном мире больших дисков я не вижу реальной причины разбивать дерево ОС. Пользовательские данные, да. Но отдельные разделы для / var и / usr и / var / spool и т. Д. И т. Д. И т. П.? Нет.
(1) = и я знаю, просто выбрав этот размер, я получу кого-то в комментариях, говорящих 10 МБ? Luxury. Почему наши диски были просто ...
источник
В ответ на :
На Linux-машине для предотвращения этого используется LVM (управление логическими томами). Большинство файловых систем позволяют изменять размеры (некоторые даже онлайн). Я создаю разные разделы для разных целей и форматирую их для разных файловых систем (например, xfs для больших загружаемых файлов, которые я могу быстро удалить). Нужно больше места? Смонтируйте новый диск, переместите данные на него, затем смонтируйте его там, где раньше были данные. Это абсолютно незаметно для пользователей и приложений.
С помощью LVM вы можете добавить диски или разделы в группу томов, а затем создать логические тома в этой группе. Если вы оставите свободное место в группе томов, вы сможете увеличить разделы, которые заполняются. Если файловая система поддерживает это (ext3, ext4, reiserfs), вы можете уменьшить раздел, который вы перераспределили.
Например: сделать загрузочный раздел в / dev / sda1, создать второй (неформатированный) раздел / dev / sda2
Когда вам нужно больше места на / загрузки (пока смонтирована файловая система):
И теперь у вас есть раздел загрузки 150GB. Похоже на дом. На самом деле я только что изменил размер раздела ext4 lvm. С другой стороны, логические тома на самом деле не являются разделами, и то, что вы говорите о разделах неправильного размера, соответствует моему личному опыту (больше проблем, чем они того стоят).
источник
Традиционная схема разбиения Unix, безусловно, является старой практикой, которая не так полезна, как раньше. В то время, когда время работы системы Unix измерялось годами, и десятки сотен пользователей возились с оболочками, монтирование / usr в режиме «только чтение» было полезным способом защиты системы. Теперь перемонтирование файловых систем к патчу кажется более трудоемким и не очень полезным.
В моем старом университете в старые добрые времена кластеры Unix имели файловые системы только для чтения со стандартными инструментами Unix, а дополнительные приложения находились в / usr / local, который представлял собой NFS, а затем файловую систему AFS. Частично это было удобно ... кто хотел перекомпилировать программное обеспечение на дюжине блоков в кластере, когда можно было запускать приложения в высокоскоростной сети 4 МБ или 10 МБ? Сегодня, с приличными менеджерами пакетов и большим количеством дешевых дисков, это не так уж важно.
Я думаю, что мыслительные процессы начали меняться для меня на Sun box с Veritas Volume Manager примерно в 1999 году, что значительно снизило порог боли при перемещении дисков.
Сегодня, когда я думаю о разделении, я думаю о защите данных и производительности. Наглядный пример:
Эти соображения применимы и к Windows. У нас есть сервер SCCM, который управляет около 40 тыс. Клиентов. База данных и журналы находятся на мегакрахтовом диске IBM DS8000. Пакеты программного обеспечения находятся на EMC Celerra с большими медленными дисками SATA, стоимость которых на 60 ГБ меньше.
источник
Я понимаю, что этот вопрос не зависит от ОС, верно?
Под Windows я стараюсь дать всем моим машинам как можно меньше разделов, но не менее двух - SYSTEM и DATA. Если на машине два физических диска, то один (меньший) будет SYSTEM, а другой - DATA. Если есть только один диск, я делю его на два раздела.
Причина этого только одна - когда мне нужно переустановить компьютер (и будет такое время), мне не нужно беспокоиться о содержимом раздела SYSTEM - я просто делаю полный формат на нем и чистая установка. Это, конечно, означает, что мои Документы (и, предпочтительно, Desktop) должны быть сопоставлены с папкой на DATA, но это легко сделать, особенно в Vista и более поздних версиях.
Я также попытался создать больше партий (таких как ИГРЫ, МУЗЫКА, ФИЛЬМЫ и т. Д.), Но это привело к тому, что некоторые из них перетекли в другие, создавая больше беспорядка, чем порядка.
источник
(Предполагая, что доступен один большой диск), я поместил
home
иvar
на отдельные разделы, чтобы управлять проблемой «из-под контроля [пользователь | файл журнала] заполняет все пространство», и чтобы можно было легко обновлять ОС, не касаясь дома, но оставив отдыхать вместеНа старом оборудовании иногда требовалось иметь отдельный
boot
раздел, чтобы гарантировать, что образ ядра доступен для загрузчика.источник
Вы упоминаете о заполнении одного диска, в то время как на другом есть свободное место - это одна из причин, по которой я делю разделы, - потому что я могу гарантировать, что некоторые разделы не заполняются. Несмотря на то, что ранее использовались способы управления квотами, вам нужно было бы назначить всем пользователям квоту 0 для других разделов, просто чтобы убедиться, что они не начали скрывать файлы, если им удалось найти каталог, который они мог бы написать
Что касается упрощения резервного копирования - если я знаю, какой будет максимальный размер каждого раздела, я могу убедиться, что это размер, который аккуратно умещается на одной ленте и может быть выполнен за фиксированное количество времени.
Что касается надежности, единственное, о чем я могу думать, это мониторинг - мне легче видеть, когда данный раздел растет больше, чем должно быть, и дать мне повод посмотреть на это.
... теперь, несмотря на все сказанное, мы далеки от того, чтобы каждому пользователю давали свою маленькую квоту в 20 МБ на общем компьютере. Некоторые из старых привычек не имеют смысла - но когда у вас есть процесс, сходящий с ума и заполняющий / var, который, в свою очередь, заполняет /, и все останавливается, это не так уж плохо, чтобы иметь защиту на производственных машинах ,
Для дома у меня есть разделы, но это просто, чтобы упростить управление установленными ОС.
источник
Лично я использую разделы только на компьютерах моего ребенка. Я создаю большой раздел для ОС и небольшой раздел для образа раздела ОС, чтобы при загрузке машины я мог быстро восстановить его из образа.
В корпоративной среде я никогда не слышал убедительных аргументов в пользу разделения.
источник
Все в модерации - это хорошо, это может быть хорошим инструментом для выявления проблем при сбое, таких как заполнение диска или повреждение файловой системы.
Не путайте это с аппаратными сбоями - они должны обрабатываться аппаратным резервированием (RAID)
Сказав это, файловые системы в наши дни отказывают реже - даже делают онлайн проверки целостности (например, ZFS). Так что, надеюсь, офлайн fsck уйдет в какой-то момент ...
С другой стороны, чрезмерное выполнение этого означает только больше работы (для вас и вашей команды) в конце - просто сделайте это в меру и когда это имеет смысл ...
источник