Есть ли причина, чтобы сохранить основной раздел / диск C: маленький?

историческая причина этой практики, скорее всего, коренится в эксплуатационных свойствах вращающихся магнитных жестких дисков. Область на вращающихся дисках с наибольшей скоростью последовательного доступа outermost участков (около начала привода).

Если вы используете весь привод для вашей операционной системы, то рано или поздно (через обновления ЕТК) ваши файлы операционной системы были бы распространены вне на всем поверхность диска. Таким образом, чтобы убедиться, что файлы ОС физически остаются в быстрые области диска, можно создать небольшой системный раздел в начале диска, и выкладывать остальные езды в Данные разделы, как вам нравится.

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

эта практика потеряла все свои причины с появлением SSD-накопителей.

есть ли причина, чтобы сохранить основной раздел Windows / диск C: маленький?

вот несколько причин для этого:

1. все системные файлы и сама ОС находятся на основном разделе. Лучше хранить эти файлы отдельно от другого программного обеспечения, личных данных и файлов, просто потому, что постоянное вмешательство в загрузочный раздел и смешивание ваших файлов там может иногда приводить к ошибкам, таким как удаление системных файлов или папок авария. Организация важна. Вот почему размер основного раздела низкий - чтобы пользователи не сбрасывали туда все свои данные.
2. резервное копирование - это намного проще, быстрее и эффективнее для резервного копирования и восстановления меньшего раздела, чем больший, в зависимости от назначения системы. Как отмечает @computercarguy в комментариях лучше создавать резервные копии определенных папок и файлов, чем создавать резервные копии всего раздела, если только необходимый.
3. It может улучшите представление, однако, в едва заметном образе. На NTFS файловые системы, есть так называемый Таблицы Мастер-Файлов на каждом разделе, и он содержит метаданные обо всех файлах на разделе:

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

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

другое дело Примечание, что в случае наличия SSD + HDD, это способ лучше хранить ОС на SSD и все ваши личные файлы и данные на жестком диске. Вам, скорее всего, не понадобится повышение производительности от наличия SSD для большинства ваших личных файлов, а твердотельные накопители потребительского класса обычно не имеют много места на них, поэтому вы предпочли бы не пытаться заполнить его личными файлами.

может ли кто-нибудь объяснить, почему эта практика выполняется и действует ли она до сих пор?

описал некоторые причины, по которым это делается. И да, он все еще действителен, хотя не очень хорошая практика, как кажется. Наиболее заметным минусом было то, что конечным пользователям придется следить о том, где приложений предлагают установить свои файлы и изменить расположение (возможно в практически любой установки программного обеспечения, особенно если эксперт/дополнительные установки возможность) так что загрузочный раздел не заполняют, так как ОС не нужно обновлять время от времени, и еще одним недостатком является то, что при копировании файлов из одного раздела в другой, ей на самом деле нужно, чтобы скопировать их, а если они были в одном разделе, он просто обновляет MFT и мета-данные, не нужно писать все файлы снова.

некоторые из них, к сожалению, может ввести больше проблем:

1. Оно увеличивает сложность структуры, которая делает ее более трудным и более требующий много времени управлять.
2. некоторые приложения по-прежнему записывают файлы/метаданные в системный раздел (ассоциации файлов, контекстные меню и т. д..), даже если он установлен в другом разделе, таким образом, это затрудняет резервное копирование и может привести к сбоям синхронизации между разделами. (спасибо @комментарий Боба)

чтобы избежать проблемы, вам нужно:

1. всегда пытайтесь устанавливать приложения на другие разделы (измените место установки по умолчанию).
2. обязательно устанавливать только важные программы в загрузочный раздел. Другое не-так-необходимое и неважное програмное обеспечение должно быть сдержано снаружи она.

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

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

Я разработчик программного обеспечения, но также потратил время на "регулярную" / бэк-офисную ИТ-работу. Обычно я храню ОС и приложения на диске C:, а личные файлы-на диске D:. Они не обязательно должны быть отдельными физическими дисками, но в настоящее время я использую относительно небольшой SSD в качестве своего "системного" диска (C:) и "традиционный" диск (т. е. с вращающимися магнитными пластинами) в качестве моего "домашнего" диска (D:).

все файловые системы подвержены фрагментации. С SSDs это это в основном не проблема, но это все еще проблема с традиционными дисками.

Я обнаружил, что фрагментация может существенно снизить производительность системы. Например, я обнаружил, что полная сборка большого программного проекта улучшилась более чем на 50% после дефрагментации моего диска - и эта сборка заняла большую часть часа, так что это было не тривиальная разница.

держа мои личные файлы на отдельном томе делает, я найдено:

• системный том фрагментируется не так быстро (или сильно);
• дефрагментация двух отдельных томов выполняется намного быстрее, чем дефрагментация одного тома со всем содержимым -- каждый том занимает 20% -25% от общего объема.

Я наблюдал это на нескольких поколениях ПК, с несколькими версиями Windows.

(Как отметил комментатор, это также облегчает создание копий.)

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

предостережение: С более новыми версиями Windows (начиная с 8) это стало намного сложнее, потому что пользовательские папки на томе, отличном от C:, больше официально не поддерживаются. Я могу сказать вам, что я не смог выполнить обновление с Windows 7 до Windows 10, но YMMV (есть несколько разных способов [re]найдите папку пользователя, я не знаю, какие затронуты).

еще одно примечание: если вы поддерживаете два отдельных Тома на традиционном диске, вы можете настроить файл подкачки на томе D:. По причинам, описанным в ответе WooShell, это сократит время поиска при записи в файл подкачки.

короткий ответ: не больше.

по моему опыту (более 20 лет ИТ-администрирования), основная причина этой практики (другие перечислены ниже) заключается в том, что пользователи в основном не доверяют Windows с их данными и места на жестком диске.

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

• есть много продуктов, в том числе от Microsoft, которые не удалить чисто и/или вызвать проблемы совместимости и стабильности (наиболее заметным проявлением является оставшиеся файлы и записи реестра все вокруг и DLL Hell во всех его воплощений). Многие файлы, созданные в ОС не почистил (журналы, обновления Windows и т. д.), что приводит к увеличению пространства, как время идет ОС. В Windows 95 и даже XP era совет дошел до того, что предложил чистую переустановку ОС время от времени. Переустановка ОС требовала возможности гарантировать очистку операционной системы и ее раздела ( чтобы также очистить поддельные данные в файловой системе) - невозможно без нескольких разделов. И разделять привод снаружи потеря данных возможна только с помощью специализированных программ (у которых могут быть свои неприятные сюрпризы, такие как спасение и оставление данных в непригодном состоянии при столкновении с плохим сектором). Различные программы "очистки" облегчили проблему, но их логика, основанная на обратном инжиниринге и наблюдаемом поведении, с еще большей вероятностью вызовет серьезную неисправность, которая заставит переустановку (например,RegClean утилита самой MS была отменена после выпуска Office 2007, который нарушил предположения о реестре, на котором он был основан). Тот факт, что многие программы сохраняли свои данные в произвольных местах, еще более усложнял разделение данных пользователя и ОС, заставляя пользователей устанавливать программы за пределами иерархии ОС.
  • Microsoft пыталась несколько способов повышения стабильности, с разной степенью успеха (общие библиотеки DLL,Защита Файлов Windows и его преемник TrustedInstaller,бок-о-бок подсистемы,a отдельный репозиторий для модулей .NET со структурой хранения, предотвращающей конфликты версий и поставщиков). Последние версии установщика Windows даже имеют элементарную проверку зависимостей (вероятно, последний главный менеджер пакетов в общем использовании для включения этой функции).
  • что касается соответствия программного обеспечения сторонних производителей передовой практике, они маневрировали между поддержанием совместимости с небрежно написанным, но достаточно используемым программным обеспечением (в противном случае, его пользователи не будут обновление до новой версии Windows)-что приводит к ошеломляющему количеству клубней и обходных путей в ОС, включая недокументированное поведение API, Live patching сторонних программ для исправления ошибок в них и несколько уровней виртуализации реестра и файловой системы -- и между принуждением сторонних поставщиков к соблюдению таких мер, как программа сертификации логотипов и программа подписи драйверов (обязательная начиная с Перспектива.)
• пользовательские данные, похороненные под длинным путем под профилем пользователя, сделали неудобным поиск и указание путей к нему. Пути также используются длинные имена, имел пробелы (проклятие командных оболочек повсюду) и национальные символы (основная проблема для языков программирования, кроме самых последних, которые имеют всестороннюю поддержку Unicode) и были специфичными для локали (!) и недоступна без доступа к winapi (!!) (убийство любого усилия по интернационализации в скриптах), все из которых также не помогли.
  
  Таким образом, наличие ваших данных в корневом каталоге отдельного диска рассматривалось как более удобная структура данных, чем предоставленная Windows.
  • это было исправлено только в последних версиях Windows. Сами пути были исправлены в Vista, сжимая длинные имена, исключая пробелы и локализованные имена. Проблема просмотра была исправлена в Win7, который предоставил пункты меню Пуск для обоих корень Профиль пользователя и большинство других каталогов под ним и такие вещи, как постоянные" любимые " папки в диалоговых окнах выбора файлов, с разумными значениями по умолчанию, такими как Downloads, чтобы сохранить необходимость просматривать их каждый раз.
• в конце концов, усилия госпожи принесли свои плоды. грубо начиная с Win7, ОС, акции и стороннего программного обеспечения, в том числе очистки утилит, являются стабильными и хорошо себя ведут достаточно, и жесткие диски достаточно большой, для ОС не требует переустановки на полнота жизни типичного рабочего места. И иерархия запасов достаточно удобна и доступна, чтобы фактически принять и использовать ее в повседневной практике.

вторичные причины:

• раннее программное обеспечение (Поддержка файловых систем и секционирования в BIOS и ОС) отставало от жестких дисков в поддержке больших объемов данных, что требовало разделения жесткого диска на части, чтобы иметь возможность использовать его полную мощность.
  • это было в первую очередь проблема в DOS и Windows 95 раз. С появлением FAT32 (Windows 98) и NTFS (Windows NT 3.1) проблема была в значительной степени решена в настоящее время.
  • барьер 2TB, который появился недавно, был исправлен недавним поколением файловых систем (ext4 и последние версии NTFS),GPT и 4К диски.
• различные попытки оптимизации производительности. Вращательные жесткие диски немного (примерно в 1,5 раза) быстрее при чтении данных с внешних дорожек (которые сопоставляются с начальными секторами), чем с внутренними, что предполагает размещение часто используемых файлов, таких как библиотеки ОС и файл подкачки, в начале диска.
  • поскольку доступ к пользовательским данным также осуществляется очень часто, а перемещение головок оказывает еще большее влияние на производительность, за исключением очень специфических рабочих нагрузок, улучшение использования в реальной жизни в лучшем случае незначительно.
• несколько физических диски. Это нетипичная установка для рабочей станции, так как современный жесткий диск часто достаточно большой сам по себе, а ноутбуки даже не имеют места для 2-го жесткого диска. Большинство, если не все станции, которые я видел с этой установкой, являются настольными компьютерами, которые (повторно)используют старые жесткие диски, которые все еще работают и добавляют до необходимого размера-в противном случае следует использовать либо RAID, либо один из дисков должен содержать резервные копии и не использоваться регулярно.
  • это, вероятно, единственный случай, когда один получает реальную выгоду от разделения системы и данных на отдельные тома: поскольку они физически находятся на разных аппаратных средствах, к ним можно получить доступ параллельно (если только это не два диска PATA на одном кабеле), и при переключении между ними нет снижения производительности при перемещении головы.
    • для повторного использования структуры каталогов Windows, я typicaly движение C:\Users на диск данных. перемещение только одного профиля или даже просто Documents,Downloads и Desktop оказались слабее, потому что другие части профиля и Public может также расти бесконтрольно (см. "настройка отдельной конфигурации и данных" ниже).
  • хотя диски можно объединить в Тома, я не использую или рекомендую это, потому что динамические Тома являются запатентованной технологией, с которой сторонние инструменты имеют проблемы при работе, и потому, что если какой-либо из дисков выходит из строя, весь том теряется.
• М. 2 ССД + ВИНЧЕСТЕР.
  • в этом случае я скорее рекомендую использовать SSD исключительно в качестве кэша: таким образом, вы получаете преимущество SSD для всего вашего массива данных, а не только какой-то произвольной его части, и то, что ускоряется, определяется автоматически тем, что вы на самом деле получаете доступ на практике.
  • в любом случае, эта установка в компьтер-книжке плохонька к как раз одиночному SSD ' HDDs cuz также нетолерантна к внешним удару и вибрации которые очень реальные возникновения для ноутбуки.
• сценарии двойной загрузки. Как правило, две операционные системы не могут сосуществовать в одном разделе. Это единственный известный мне сценарий, который требует наличия нескольких разделов на рабочей станции. И случаи использования для этого исчезают редко в наши дни, потому что каждая рабочая станция теперь достаточно мощна для запуска виртуальных машин.
• на серверах существует ряд других допустимых сценариев, но ни один из них не применяется к домену суперпользователя.
  • Е. Г. можно отделяйте постоянные данные (программы и конфигурацию) от изменяющихся данных (данные приложений и журналы), чтобы предотвратить взлом всей системы. Также различные специальные потребности (например в врезанной системе, упорние данные часто пребывают на EEPROM пока данные по работы на приводе RAM). Linux Стандарт Файловой Иерархии прекрасно подходит для настроек такого рода.

почти 2 десятилетия назад доминировал бы диапазон от Windows 98 до XP, включая NT4 и 2000 на стороне рабочей станции/сервера.

все жесткие диски также будут PATA или SCSI кабелем магнитного хранения, как SSD стоят больше, чем компьютер, и SATA не существует.

Как говорит ответ WooShell, нижние логические сектора на диске (за пределами platter), как правило, самые быстрые. Мой 1ТБ велоцираптор диски МЦД начать в 215MB/S, но падает вниз 125MB / s на наружных участках, падение 40%. И это 2,5-дюймовый дисковый диск, поэтому большинство 3,5-дюймовых дисков обычно видят все большее падение производительности,больше 50%. Это основная причина, по которой основной раздел остается небольшим, но он применяется только в том случае, если раздел мал относительно размера диска.

другая основная причина, чтобы сохранить небольшой раздел был, если вы используете FAT32 в качестве файловой системы, которая не поддерживает разделы больше, чем 32GB. Если вы использовали NTFS, разделы размером до 2 ТБ поддерживались до Windows 2000, а затем до 256 ТБ.

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

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

Так это еще хорошая идея, или есть ли выгода? Это зависит от того, какие данные вы храните и как ими управляете. Моя рабочая станция C: составляет всего 80 ГБ, но сам компьютер имеет более 12 ТБ памяти, распределенной по нескольким дискам. Каждая секция содержит только определенный тип данных, и размер кластера совпадает и с типом данных и с размером секции, который поддерживает фрагментацию около 0 и не позволяет MFT быть неоправданно большим.

размер меньше, что есть неиспользуемое пространство, но увеличение производительности более чем компенсирует, и если я хочу больше памяти, я добавляю больше дисков. С: содержит операционную систему и часто используемые приложения. П: содержит менее часто используемых приложений, и 128 ГБ SSD с оценкой меньшая долговечность, чем на C:. T: находится на меньшем SSD-накопителе SLC и содержит временные файлы пользователя и операционной системы, включая кэш браузера. Видео - и аудиофайлы, а также образы виртуальных машин, резервные копии и архивные данные сохраняются на магнитном носителе, они обычно имеют размер кластера 16 КБ или больше, а для чтения и записи преобладает последовательный доступ. Я запускаю defrag только один раз в год на разделах с большим объемом записи, и это занимает около 10 минут, чтобы сделать всю систему.

мой ноутбук имеет только один 128 ГБ SSD и другой вариант использования, поэтому я не могу сделать то же самое, но я все еще разделяюсь на 3 раздела, C: (80 ГБ ОС и программы), T: (8 ГБ temp) и F: (24 ГБ пользовательских файлов), что делает хорошую работу по контролю фрагментации не теряя места, и ноутбук будет заменен задолго до того, как закончится место. Это также упрощает резервное копирование, так как F: содержит единственные важные данные, которые регулярно меняются.

Я использовал, чтобы сделать некоторые ИТ-работу, и вот то, что я знаю и помню.

в прошлом, как говорили другие, было реальное преимущество наличия небольшого раздела C в начале диска. Даже сегодня в некоторых ноутбуках нижнего конца это может быть правдой. По сути, имея меньший раздел, у вас меньше фрагментации, и, сохраняя его в начале диска, вы лучше ищете и, следовательно, читаете. Это все еще действительно сегодня с ноутбуками (обычно) и более медленным" зеленым " жестким приводы.

еще одно большое преимущество, которое я до сих пор использую сегодня, - это наличие "данных" и "ОС" на отдельных дисках, или если я не могу управлять этими отдельными разделами. Нет никакого реального увеличения скорости при использовании SSD или даже более быстрых магнитных дисков, но есть огромная опция "easy fix", когда ОС в конечном итоге резервуары. Просто замените диск или повторно призрак этого раздела. Данные пользователя не повреждены. При правильной настройке между диском D: и "перемещаемыми профилями" переустановка windows занимает 5 минут. Она делает его хорошим шагом для техники 1-го уровня.

вот одна из причин, но я не считаю, что это веская причина для сегодняшних (современных) компьютеров.

Это восходит к Windows 95/98 и XT. Вероятно, это не относится к Vista и более поздним версиям, но это было аппаратное ограничение, поэтому для запуска новой ОС на старом оборудовании все равно придется иметь дело с ограничением.

Я считаю, что ограничение было 2 Гб, но могло быть ограничение 1 ГБ (или, возможно, другие) в более раннее время.

проблема была (что-то like) это: загрузочный раздел должен быть в пределах первых 2 ГБ (возможно, 1 ГБ раньше) физического пространства на диске. Могло случиться так, что 1) начало загрузочного раздела должно было быть в пределах лимита, или 2) весь загрузочный раздел должен был быть в пределах лимита. Возможно, в разное время каждый из этих случаев применялся, но если #2 применялся, это было, вероятно, недолго, поэтому я предполагаю, что это № 1.

Итак, с #1, начало загрузочного раздела должно быть, в пределах первых 2 ГБ физического пространства. Это не помешает сделать 1 большой раздел для Boot / OS. Но, проблема была двойной / мульти загрузки. Если казалось, что когда-нибудь хотеть двойной/мульти-загрузочный диск, там должна быть свободная площадь под 2 ГБ марка для создания других загрузочных разделов на диске. Поскольку во время установки может быть неизвестно, понадобится ли диску другой загрузочный раздел, скажем, Linix или какой-либо загрузочный раздел отладки/устранения неполадок/восстановления, это было часто рекомендуется (и часто не зная, почему) установить на "маленький" загрузочный раздел ОС.

Мне интересно, если ваш десятилетиями ИТ-отдел был обеспокоен резервного копирования. Поскольку C: является разделом boot / OS, обычно используется некоторый тип резервного копирования образа, но для раздела data / program может использоваться инкрементная резервная копия файла + папки. Сокращение пространства, используемого в разделе C:, сократит время и пространство, необходимые для резервного копирования системы.

комментарий о моем личном использовании раздела C:. У меня есть мультизагрузочная система, включая Win 7 и Win 10 и у меня нет ОС на разделе C:, только загрузочные файлы. Я использую Windows резервной копии образа системы для Win 7 и Win 10, и время выполнения архивации образа системы всегда включает в себя с: (загрузочный) раздел, в дополнение к Win 7 или Win 10 разделов, так что это еще один сценарий, где уменьшение количества данных и программ на диск C: сокращает время и пространство, необходимое для образ системы резервного копирования (или восстановления, если это необходимо).

Я оставляю этот раздел в своем ответе из-за комментариев ниже.

Так как моя система мультизагрузочная, перезагрузка в другую ОС делает резервное копирование разделов данных / программ проще, так как нет никакой активности на разделах во время их резервного копирования. Я написал простой программы резервного копирования, что делает папку + файл копировать наряду с безопасностью и повторной обработки инфо, но он не совсем работает для Win 7 или Win 10 ОС перегородок, поэтому я использую образ системы резервного копирования для С;, Win 7 и Win 10 ОС разделов.

нет, не с Windows и ее основными пакетами программного обеспечения, настаивающими на связи с системой: несмотря на установку их в программы:. (Это институционализированная необходимость, как строится большинство ОС.) Данные: том имеет смысл, но отдельный съемный диск для ваших данных (или NAS, или выборочные или инкрементные резервные копии на такой съемный диск) имеет еще больший смысл.

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

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

есть одна конкретная причина - использование снимков Тома.

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

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

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