Я часто задавался вопросом, почему существует такая страсть к разделению дисков, особенно в операционных системах Unixy (/ usr, / var и др.). Это не похоже на обычную тему для установок Windows.
Кажется, что разбиение на разделы значительно увеличивает вероятность заполнения одного раздела, в то время как другие имеют много свободного места. Очевидно, этого можно избежать путем тщательного проектирования и планирования, но все может измениться. Я испытал это на машинах много раз, в основном на тех, которые были установлены другими, или с настройками по умолчанию для данной ОС.
Еще один аргумент, который я слышал, заключается в том, что это упрощает резервное копирование. Как это упрощает резервное копирование? Я также слышал, что это повышает надежность. Опять же, как?
Почти 100% проблем, с которыми я сталкивался с дисковым хранилищем, связаны с физическим отказом диска. Можно ли утверждать, что разбиение на разделы может потенциально ускорить сбой оборудования из-за перегрузки диска при перемещении или копировании данных из одного раздела в другой на том же диске?
Я не пытаюсь слишком сильно раскачивать лодку, я просто хотел бы увидеть оправдание вековой административной практике.
Я не думаю, что создание большого количества разделов - это то, что вам нужно делать для каждой системы. Лично на большинстве моих серверов Linux я просто устанавливаю один большой раздел. Поскольку большинство моих систем имеют небольшие диски и являются одноцелевыми и обслуживают некоторую роль инфраструктуры (DNS, DHCP, межсетевой экран, маршрутизатор и т. Д.). На своих файловых серверах я создаю разделы, чтобы отделить данные от системы.
Можно ли утверждать, что разбиение на разделы может потенциально ускорить сбой оборудования из-за перегрузки диска при перемещении или копировании данных из одного раздела в другой на том же диске?
Я очень сомневаюсь, что хорошо разделенная система будет иметь повышенную вероятность отказа.
Одна из причин сохранить / home / seperate - вы можете переустановить операционную систему и никогда не беспокоиться о потере пользовательских данных. Помимо этого, необходимо обеспечить большую безопасность при монтировании всего либо только для чтения, либо noexec. Если пользователи не могут запускать код там, где они могут писать, это на один вектор атаки меньше.
Я бы стал беспокоиться об этом только на общедоступной машине, поскольку недостаток дискового пространства в одном разделе, но наличие его в другом, является серьезным раздражением. Есть способы обойти это, например, сделать программный рейд или ZFS, где вы должны иметь возможность легко динамически изменять размер разделов, но у меня нет опыта с ними.
Вы можете делать резервные копии (с помощью dumpfs или подобного) того, что хотите, а не того, чего вы не делаете. dump (1) - лучшая система резервного копирования, чем tar (1).
Это тоже аргумент в пользу разделения. Пользователи, заполняющие свои домашние компьютеры, не разрушают сервер, не отключают веб-сервер, не препятствуют ведению журналов, не препятствуют входу root и т. Д.
Это также позволяет более прозрачно переместить часть ваших данных (скажем, / home) на другой диск: скопировать ее, смонтировать. Если вы используете что-то, что позволяет создавать теневые копии / снимки / что-то еще, вы даже можете делать это вживую.
Меня всегда учили хранить / var в отдельном разделе, поэтому, если вы получите неконтролируемый файл журнала, вы забьете один раздел, а не весь диск. Если он находится на том же месте, что и остальная часть системы, и вы на 100% заполните свой диск, он может выйти из строя и произвести неприятное восстановление.
Все аргументы, выдвигаемые Зоредашем, верны; можно немного придраться к деталям (наличие машины быстрее, чтобы вы могли делать другие вещи, в то время как fsck'ing других файловых систем не принесет вам много пользы, если причина существования системы в первую очередь связана с этими другими файловыми системами) ; однако все они являются своего рода оправданием постфактум.
Во времена старой школы у вас не было файловых систем на отдельных разделах - они были на разных дисках, потому что диски были очень маленькими. Подумайте, 10 МБ. (1) Итак, у вас был крошечный раздел /, диск / var, диск / usr, диск / tmp и диск / home. Если вам нужно больше места, вы купили другой диск.
Затем «большие» диски объемом 50 Мбайт стали стоить меньше, чем программа Moon, и внезапно появилась возможность разместить всю систему на одном диске с полезным объемом пользовательского пространства.
Тем не менее, поскольку размеры дисков были небольшими по сравнению с тем, что мог создать компьютер, изоляция / var, / opt и / home, чтобы заполнение одного диска не приводило к поломке компьютера, все еще была хорошей идеей.
Сегодня в корпоративной ситуации я не разбиваю ОС на разделы. Данные разделяются, особенно если они созданы пользователем; но часто это связано с тем, что это происходит на высокоскоростных и / или избыточных дисковых массивах. Однако / var и / usr находятся в том же разделе, что и /.
В домашней среде то же самое - / home, вероятно, должно быть на отдельном диске / массиве, чтобы можно было установить / обновить / сломать / исправить любые желаемые варианты ОС.
Причина этого в том, что независимо от того, насколько велико ваше / var или / usr или какое-либо другое дерево, вы либо ошибаетесь, либо смехотворно переоцениваете. Один из моих старых коллег по школе ругается разделением, и я всегда горюю от него, когда он просидел 180-дневный fsck в системе, которую я создал. Но я могу подсчитать по пальцам одной руки за всю мою карьеру, сколько раз что-то наполнялось / приводило к остановке системы, в то время как я могу сосчитать одной рукой, сколько раз в этом году я смотрел на систему, в которой кто-то решил, что / var никогда не должен быть больше, чем (скажем) 1 ГБ, и ошибся, оставив меня смотреть на полный / var и нулевые бесплатные ГБ в другом месте в системе, все из которых с таким же успехом могли быть на Луне для всех то хорошее, что они мне делают.
В сегодняшнем мире больших дисков я не вижу реальной причины для разбиения дерева ОС. Данные пользователя, да. Но отдельные разделы для / var и / usr и / var / spool и т. Д. И т. Д.? Нет.
(1) = и я знаю, что просто выбрав этот размер, я получу в комментариях, что кто-нибудь скажет 10 МБ? Роскошь. Почему наши диски были просто ...
В ответ на :
Кажется, что разбиение на разделы значительно увеличивает вероятность заполнения одного раздела, в то время как в других имеется много свободного места.
На машине 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
Если вам нужно больше места на / downloads (пока файловая система смонтирована):
lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads
И теперь у вас есть раздел загрузки 150 ГБ. Аналогично для дома. Фактически, я только что изменил размер "раздела" ext4 lvm. С другой стороны, логические тома на самом деле не являются разделами, и то, что вы говорите о разделах неправильного размера, согласуется с моим личным опытом (больше проблем, чем они того стоят).
Традиционная схема разделения Unix - это определенно старая школьная практика, которая уже не так полезна, как раньше. В те времена, когда время безотказной работы Unix-системы измерялось годами, и у вас были десятки сотен пользователей, которые возились с оболочками, монтирование / usr как доступного только для чтения было полезным способом защиты системы. Теперь перемонтирование файловых систем для исправления кажется более трудоемким и не таким полезным.
В моем университете в старые добрые времена кластеры Unix имели файловые системы, доступные только для чтения, со стандартными инструментами unix, а дополнительные приложения находились в / usr / local, который был файловой системой NFS, а затем и AFS. Частично это было удобством ... кто хотел перекомпилировать программное обеспечение на дюжине компьютеров в кластере, когда вы могли запускать приложения в высокоскоростной сети, 4 или 10 МБ? Сегодня, с хорошими менеджерами пакетов и большим количеством дешевых дисков, это не так уж важно.
Я думаю, что мыслительные процессы начали меняться для меня в коробках Sun с Veritas Volume Manager примерно в 1999 году, что значительно снизило порог боли при перемещении дисков.
Сегодня, когда я думаю о секционировании, я думаю о защите данных и производительности. Наглядный пример:
Эти соображения применимы и к Windows. У нас есть сервер SCCM, который обслуживает около 40 тысяч клиентов. База данных и журналы находятся на супер-экономичном диске IBM DS8000. Пакеты программного обеспечения находятся на EMC Celerra с большими медленными дисками SATA, которые стоят на 60% меньше за 1 ГБ.
Я понимаю, что этот вопрос не зависит от ОС, верно?
Под Windows я обычно делаю все свои машины как можно меньше разделов, но не меньше двух - SYSTEM и DATA. Если на машине два физических диска, то один (меньшего размера) будет СИСТЕМНЫМ, другой ДАННЫМ. Если есть только один диск, я разбиваю его на два раздела.
Причина всего одна - когда мне нужно переустановить машину (а такое время будет), мне не нужно беспокоиться о содержимом раздела SYSTEM - я просто выполняю полное форматирование на нем и чистая установка. Это, конечно, означает, что мои документы (и, желательно, также рабочий стол) должны быть сопоставлены с папкой на DATA, но это легко сделать, особенно в Vista и более поздних версиях.
Я также пробовал делать больше партитонов (например, ИГРЫ, МУЗЫКА, ФИЛЬМЫ и т. Д.), Но это привело только к тому, что некоторые из них перетекали в другие, создавая больше беспорядка, чем порядок.
(Предполагая, что доступен один большой диск), я поставил home и var на отдельных разделах, чтобы контролировать проблему «неконтролируемого [пользователь | файл журнала], заполняющего все пространство», и чтобы можно было легко обновлять ОС, не касаясь дома, но оставив остальное вместе.
На более старом оборудовании иногда требовалось иметь отдельный boot убедитесь, что образ ядра был доступен загрузчику.
Вы упоминаете о заполнении одного диска, в то время как на другом есть свободное место - это одна из причин, по которой я разбиваю разделы - потому что я могу гарантировать, что определенные разделы не заполнять. Хотя, как раньше использовалось управление квотами, вам пришлось бы назначить всем пользователям квоту 0 на других разделах, просто чтобы убедиться, что они не начали скрывать файлы, если им удалось найти каталог, который они мог написать.
Что касается упрощения резервного копирования - если я знаю, каков будет максимальный размер каждого раздела, я могу убедиться, что этот размер аккуратно умещается на одной ленте и может быть завершен за фиксированный промежуток времени.
Что касается надежности, единственное, о чем я могу думать, - это мониторинг - мне легче увидеть, когда данный раздел разрастается больше, чем должен быть, и дать мне повод изучить это.
... теперь, как говорится, мы далеки от того времени, когда каждому пользователю давалась небольшая квота в 20 МБ на общей машине. Некоторые из старых привычек не имеют смысла, но когда у вас есть процесс, который сходит с ума и заполняет / var, который, в свою очередь, заполняет /, и все останавливается, это не так уж плохо для защиты на производственных машинах .
Для дома у меня есть разделы, но это просто для облегчения управления установленными операционками.
Лично я использую разделение только на компьютерах моего ребенка. Я создаю большой раздел для ОС и небольшой раздел для образа раздела ОС, чтобы, когда машина заглохла, я мог быстро восстановить его из образа.
В корпоративной среде я никогда не слышал убедительных аргументов в пользу разделения.
Все в модерации - это хорошо - это может быть хорошим инструментом для выявления проблем в случае неисправности, например, переполнения диска или повреждения файловой системы.
Не путайте это с аппаратным отказом - с этим следует справляться с помощью аппаратного резервирования (RAID).
При этом файловые системы в наши дни выходят из строя реже - некоторые даже проводят онлайн-проверки целостности (например, ZFS). Так что, надеюсь, автономный fsck в какой-то момент исчезнет ...
С другой стороны, чрезмерное выполнение этого означает только больше работы (для вас и вашей команды) в конце - просто делайте это умеренно и тогда, когда это имеет смысл ...