Продай мне разделы

46

Я часто задавался вопросом, почему существует такая страсть к разделению дисков, особенно в ОС Unixy (/ usr, / var, et al). Это не похоже на общую тему с установками Windows.

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

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

Почти 100% проблем, с которыми я столкнулся с дисковым хранилищем, связано с физическим отказом диска. Можно ли утверждать, что разбиение диска может потенциально ускорить сбой оборудования из-за перегрузки диска при перемещении или копировании данных из одного раздела в другой на том же диске?

Я не пытаюсь раскачивать лодку слишком сильно, я просто хотел бы увидеть оправдание для давней админской практики.

Zimmy-DUB-Zongy-Цзун-Dubby
источник
В облаке «Инфраструктура как служба» разделы являются спорными, поскольку диски (обычно называемые томами) можно подключать с такой гибкостью.
Skaperen

Ответы:

41
  • Быстрее фск. Допустим, ваша система по какой-то причине отказывает, и когда она перезагружается, ей нужно запустить fsck. С действительно большим разделом, который fsck может занять вечно, и ничто в системе не будет работать, пока не будет завершен fsck всей системы. Если вы разделите систему так, чтобы корневой раздел был довольно маленьким, вы могли бы запустить систему и запустить некоторые основные службы, ожидая завершения fsck больших томов.
    • Если ваша система имеет небольшие диски или в системе только один сервис, это может не иметь большого значения.
    • В случае файловых систем с журналированием это может не иметь значения большую часть времени, но иногда даже с файловой системой с журналированием вы должны запускать полный fsck.
  • Улучшенная безопасность, потому что вы можете монтировать fs только для чтения.
    • Например, никто не должен писать в / usr при обычном использовании. Так почему бы просто не смонтировать файловую систему, чтобы она была доступна только для чтения. Наличие файловых систем только для чтения, когда их не нужно записывать, предотвратит некоторые атаки со стороны сценариев и может помешать вам уничтожать вещи, когда вы этого не имеете в виду.
    • Это может усложнить обслуживание системы, поскольку вам потребуется перемонтировать ее в режим чтения-записи, когда вам нужно применить обновления.
  • Улучшена производительность, функционал для конкретной услуги / использования.
    • Некоторые файловые системы больше подходят для определенных сервисов / приложений, или они позволяют вам настроить файловую систему так, чтобы в некоторых случаях она работала лучше. Возможно, у вас есть файловая система с большим количеством маленьких файлов, и вам нужно больше inode. Или, может быть, вам нужно хранить несколько больших файлов, образы виртуальных дисков.

Я не думаю, что установка большого количества разделов - это то, что вы должны делать для каждой системы. Лично на большинстве Linux моих серверов я просто настраивал один большой раздел. Так как большинство моих систем имеют небольшие диски и имеют одно назначение и выполняют некоторые функции инфраструктуры (dns, dhcp, firewall, router и т. Д.). На моих файловых серверах я делаю разделы настройки, чтобы отделить данные от системы.

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

Я очень сомневаюсь, что хорошо разделенная система будет иметь большую вероятность отказа.

Zoredache
источник
9
+1 И безопасность, и готовность к стихийным бедствиям осуществляется в несколько слоев. Мне нравится думать о перегородках, похожих на переборки на корабле. Они там, так что если что-то катастрофическое случится в одном сегменте корабля, корабль в целом не обязательно подвергнется риску. Поэтому, когда происходит повреждение файловой системы, ущерб несколько сдерживается. Аналогично, с точки зрения безопасности, если / homes смонтирован как noexec, он может предотвратить некоторые типы атак, если учетная запись пользователя скомпрометирована, например, из-за слабого пароля.
3dinfluence
1
Известные эксплойты работают только на разделах, смонтированных с noexec или ro. настоящая безопасность не направлена ​​на разделение, но разделение может помочь в ограничении ущерба (например, cfr. logs flood)
drAlberT
19

Одна из причин оставить / home / seperate в том, что вы можете переустановить операционную систему и не беспокоиться о потере пользовательских данных. Кроме того, при монтировании всего, что доступно только для чтения, или noexec, необходимо обеспечить большую безопасность. Если пользователи не могут запустить код где-либо, где они могут написать код, это на один вектор атаки меньше.

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

пол
источник
разделение / home звучит как настольная вещь. На серверах данные часто находятся в каком-то другом месте, например / var / www, / srv. Я бы сказал, что ваша идея должна заключаться в разделении пользовательских данных везде, где они хранятся, а не только в том случае, если они находятся в / home.
Zoredache
на машинах, используемых для научной обработки, для значительного числа людей характерно иметь учетные записи оболочки. В этом случае отдельный / домашний раздел может быть весьма полезным.
jay_dubya
Если у вас есть значительное количество машин, часто / home является монтированием NFS с файлового сервера, который логически имеет / home в своем собственном разделе из-за вышеупомянутых проблем.
Мэтт Симмонс
Пользователи часто будут использовать все доступное пространство, и это может привести к катастрофическим последствиям для услуг, предоставляемых сервером. Только предоставление им доступа для записи в отдельный раздел защищает сервер от сбоев из-за полного корневого раздела. Размещение файлов журналов в отдельном разделе делает то же самое.
Крис Нава
Я думаю, что дисковые квоты и ротация журналов - лучшее решение проблемы с пространством, но отдельные разделы действительно представляют собой хороший механизм обеспечения безопасности в крайнем случае
полу
13
  • Упрощение резервного копирования

Вы можете делать резервные копии (с помощью dumpfs или подобного) из того, что вы хотите, а не из того, что вы не делаете. dump (1) - лучшая система резервного копирования, чем tar (1).

  • Заполнение разделов

Это также аргумент в пользу разделения. Пользователи, заполняющие свои домашние каталоги, не разрушают сервер, не отключают веб-сервер, не допускают появления журналов, не позволяют войти в систему и т. Д.

Это также позволяет вам более прозрачно переместить часть ваших данных (скажем, / home) на другой диск: скопировать его, смонтировать. Если вы используете что-то, что позволяет теневые копии / снимки / что угодно, вы даже можете сделать это вживую.

Билл Вайс
источник
9

Меня всегда учили хранить / var на отдельном разделе, поэтому, если вы получите файл журнала из-под контроля, вы засорете один раздел, а не весь диск. Если он находится в том же пространстве, что и остальная часть системы, и вы на 100% заполняете весь диск, он может выйти из строя и привести к неприятному восстановлению.

Skaughty
источник
1
Я могу рассчитывать на одну руку в течение моей 15-летней (что? Скажем, это не так!) Карьеры, сколько раз я потерял систему из-за того, что из-за сбитого файла журнала (или чего-то еще) сломался компьютер. С другой стороны, я могу посчитать, с одной стороны, сколько раз в этом году я зашел в тупик, потому что кто-то решил, что / var никогда не понадобится больше 1 ГБ, и ошибся, из-за чего я посмотрел на 00 бесплатных GB in / opt, все из которых могли бы быть на Луне, несмотря на все то хорошее, что мне это дает. (Я против разделения. :)
Дэвид Макинтош
Я согласен с Дэвидом, который имел абсолютно одинаковый опыт работы как с Linux, так и с Windows. Если нет веских причин, чтобы поступить иначе, каждый диск (или массив raid) получает один раздел.
Джон Гарденерс
Ну, на этой неделе это, наконец, произошло в системе Windows. McAfee выпустил большое обновление. У нас было около 5-10 систем, которым это не нравилось. Антивирус попытается установить, создать файл журнала размером 35 МБ и повторить попытку. 1500 раз спустя у меня было 0KB бесплатно и система, в которую нельзя было войти.
Skaughty
8

Все аргументы, выдвигаемые 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. Почему наши диски были просто ...

Дэвид Макинтош
источник
На самом деле размер диска составлял 10 МБ, когда я впервые услышал кого-то: «XXX FooBytes: больше памяти, чем мне когда- либо понадобится!». Хотя я и молод, так что это было около 1982 года. Другие значения были 40 МБ, 320 МБ, 2,5 ГБ, 40 ГБ, ... данные расширяются для заполнения доступного хранилища.
dmckee
5

В ответ на :

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

На Linux-машине для предотвращения этого используется LVM (управление логическими томами). Большинство файловых систем позволяют изменять размеры (некоторые даже онлайн). Я создаю разные разделы для разных целей и форматирую их для разных файловых систем (например, xfs для больших загружаемых файлов, которые я могу быстро удалить). Нужно больше места? Смонтируйте новый диск, переместите данные на него, затем смонтируйте его там, где раньше были данные. Это абсолютно незаметно для пользователей и приложений.

С помощью LVM вы можете добавить диски или разделы в группу томов, а затем создать логические тома в этой группе. Если вы оставите свободное место в группе томов, вы сможете увеличить разделы, которые заполняются. Если файловая система поддерживает это (ext3, ext4, reiserfs), вы можете уменьшить раздел, который вы перераспределили.

Например: сделать загрузочный раздел в / dev / sda1, создать второй (неформатированный) раздел / dev / sda2

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

Когда вам нужно больше места на / загрузки (пока смонтирована файловая система):

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

И теперь у вас есть раздел загрузки 150GB. Похоже на дом. На самом деле я только что изменил размер раздела ext4 lvm. С другой стороны, логические тома на самом деле не являются разделами, и то, что вы говорите о разделах неправильного размера, соответствует моему личному опыту (больше проблем, чем они того стоят).

Swoogan
источник
4

Традиционная схема разбиения Unix, безусловно, является старой практикой, которая не так полезна, как раньше. В то время, когда время работы системы Unix измерялось годами, и десятки сотен пользователей возились с оболочками, монтирование / usr в режиме «только чтение» было полезным способом защиты системы. Теперь перемонтирование файловых систем к патчу кажется более трудоемким и не очень полезным.

В моем старом университете в старые добрые времена кластеры Unix имели файловые системы только для чтения со стандартными инструментами Unix, а дополнительные приложения находились в / usr / local, который представлял собой NFS, а затем файловую систему AFS. Частично это было удобно ... кто хотел перекомпилировать программное обеспечение на дюжине блоков в кластере, когда можно было запускать приложения в высокоскоростной сети 4 МБ или 10 МБ? Сегодня, с приличными менеджерами пакетов и большим количеством дешевых дисков, это не так уж важно.

Я думаю, что мыслительные процессы начали меняться для меня на Sun box с Veritas Volume Manager примерно в 1999 году, что значительно снизило порог боли при перемещении дисков.

Сегодня, когда я думаю о разделении, я думаю о защите данных и производительности. Наглядный пример:

  • SAN уровня 1 является очень быстрым, очень доступным (5-9), тиражируемым и очень дорогим. Критически важные базы данных или журналы транзакций живут там.
  • Уровень 2 SAN быстрый, доступный (4-9), дорогой. Приложения или данные с более низким приоритетом живут здесь.
  • Уровень 3 SAN доступен (4 9), дешево. Вещи, которые не чувствительны к производительности, живут там.

Эти соображения применимы и к Windows. У нас есть сервер SCCM, который управляет около 40 тыс. Клиентов. База данных и журналы находятся на мегакрахтовом диске IBM DS8000. Пакеты программного обеспечения находятся на EMC Celerra с большими медленными дисками SATA, стоимость которых на 60 ГБ меньше.

duffbeer703
источник
2

Я понимаю, что этот вопрос не зависит от ОС, верно?

Под Windows я стараюсь дать всем моим машинам как можно меньше разделов, но не менее двух - SYSTEM и DATA. Если на машине два физических диска, то один (меньший) будет SYSTEM, а другой - DATA. Если есть только один диск, я делю его на два раздела.

Причина этого только одна - когда мне нужно переустановить компьютер (и будет такое время), мне не нужно беспокоиться о содержимом раздела SYSTEM - я просто делаю полный формат на нем и чистая установка. Это, конечно, означает, что мои Документы (и, предпочтительно, Desktop) должны быть сопоставлены с папкой на DATA, но это легко сделать, особенно в Vista и более поздних версиях.

Я также попытался создать больше партий (таких как ИГРЫ, МУЗЫКА, ФИЛЬМЫ и т. Д.), Но это привело к тому, что некоторые из них перетекли в другие, создавая больше беспорядка, чем порядка.

Vilx-
источник
Это еще более применимо при работе на серверах.
SpaceManSpiff
2

(Предполагая, что доступен один большой диск), я поместил homeи varна отдельные разделы, чтобы управлять проблемой «из-под контроля [пользователь | файл журнала] заполняет все пространство», и чтобы можно было легко обновлять ОС, не касаясь дома, но оставив отдыхать вместе

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

dmckee
источник
2

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

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

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

... теперь, несмотря на все сказанное, мы далеки от того, чтобы каждому пользователю давали свою маленькую квоту в 20 МБ на общем компьютере. Некоторые из старых привычек не имеют смысла - но когда у вас есть процесс, сходящий с ума и заполняющий / var, который, в свою очередь, заполняет /, и все останавливается, это не так уж плохо, чтобы иметь защиту на производственных машинах ,

Для дома у меня есть разделы, но это просто, чтобы упростить управление установленными ОС.

Джо Х.
источник
1

Лично я использую разделы только на компьютерах моего ребенка. Я создаю большой раздел для ОС и небольшой раздел для образа раздела ОС, чтобы при загрузке машины я мог быстро восстановить его из образа.

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

joeqwerty
источник
1

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

Не путайте это с аппаратными сбоями - они должны обрабатываться аппаратным резервированием (RAID)

Сказав это, файловые системы в наши дни отказывают реже - даже делают онлайн проверки целостности (например, ZFS). Так что, надеюсь, офлайн fsck уйдет в какой-то момент ...

С другой стороны, чрезмерное выполнение этого означает только больше работы (для вас и вашей команды) в конце - просто сделайте это в меру и когда это имеет смысл ...

Лестер Чунг
источник