Чи є причина зберегти основний розділ / диск Windows: малий?

На моїх роботах майже два десятиліття тому ІТ-фахівці вважали б розмір основного розділу Windows (диск C) надзвичайно малим порівняно з іншими розділами. Вони стверджують, що цей запуск ПК працює на оптимальній швидкості без уповільнення.

Але недоліком цього є: C: накопичувач легко заповнюється, якщо його залишають невеликим, і незабаром ви не зможете встановити нове програмне забезпечення, оскільки у нього не вистачає місця. Навіть якщо я встановлюю програмне забезпечення на D: диск, частина його завжди копіюється на C: що заповнює його.

Моє запитання, чи така практика все ще гарна? Чому це робиться. Які його основні переваги, якщо такі є? Одне з очевидних - якщо основний розділ виходить з ладу, ваші дані є безпечними у вторинному.

Причиною, що я задаю це питання, є те, що я намагаюся оновити Visual Studio, а не можу, тому що в первинному розділі залишилось лише 24 Мб.

На моїх роботах майже два десятиліття тому ІТ-фахівці вважали б розмір основного розділу Windows (диск C) надзвичайно малим порівняно з іншими розділами. Вони стверджують, що цей запуск ПК працює на оптимальній швидкості без уповільнення. [...] Моє запитання, чи така практика все ще гарна?

Загалом: Ні .

У старих версіях Windows були проблеми з продуктивністю великих дисків (точніше: з великими файловими системами), головним чином через те, що файлова система FAT, що використовується в Windows, не підтримує великих файлових систем. Однак усі сучасні установки Windows використовують замість NTFS, що вирішило ці проблеми. Дивіться, наприклад, Чи значно знижується продуктивність NTFS в обсягах, більших від п'яти або шести ТБ? , що пояснює, що навіть розділи розміром з терабайт зазвичай не є проблемою.

В даний час, як правило, немає причин не використовувати один, великий C: розділ. Майкрософт встановив за замовчуванням створення єдиного великого C: накопичувача. Якщо для створення окремого розділу даних були вагомі причини, інсталятор запропонував би це - чому Microsoft повинен дозволяти вам встановлювати Windows таким чином, що створює проблеми?

Основна причина проти декількох накопичувачів полягає в тому, що вона збільшує складність - що в ІТ завжди погано. Це створює нові проблеми, такі як:

• вам потрібно вирішити, які файли потрібно поставити на який привід (і змінити налаштування належним чином, натиснути речі в інсталяторах тощо)
• деяке (погано написане) програмне забезпечення може не сподобатися, якщо його не ставлять на диск, відмінний від C:
• ви можете залишити на одній секції занадто мало вільного місця, а в іншому все ще є вільний простір, який важко виправити

Є деякі особливі випадки, коли кілька розділів все ще мають сенс:

• Якщо ви хочете подвійне завантаження, вам (як правило) потрібні окремі розділи для кожної установки ОС (але все одно лише один розділ на інсталяцію).
• Якщо у вас є більше одного накопичувача (особливо накопичувачів з різними характеристиками, наприклад, SSD і HD), ви можете вибрати і вибрати, що йде куди - у такому випадку це може мати сенс, наприклад, поставити диск C: на SSD і D : на HD.

Щоб вирішити деякі аргументи, часто висловлені на користь малих / окремих розділів:

• невеликі перегородки легше резервного копіювання

Вам дійсно слід створити резервну копію всіх своїх даних, так як розділити їх на розділи не дуже допоможе. Крім того, якщо вам це дійсно потрібно зробити, все програмне забезпечення для резервного копіювання, яке я знаю, дозволяє вибірково створювати резервну копію частини розділу.

• якщо одна секція пошкоджена, інший розділ все ще може бути нормальним

Хоча це теоретично вірно, немає жодних гарантійних збитків, які добре обмежуватимуться одним розділом (а ще важче перевірити, щоб у цьому переконатися у разі проблем), тому це дає лише обмежену гарантію. Плюс до того, якщо у вас є хороші резервні резервні копії, додаткова безпека зазвичай мала, щоб вартий клопоту. І якщо у вас немає резервного копіювання, у вас є набагато більші проблеми ...

• якщо ви розмістите всі дані користувача на розділі даних, ви можете стерти і перевстановити / не створити резервну копію розділу ОС, оскільки там немає даних користувача

Хоча це може бути справедливим у теорії, на практиці багато програм записують налаштування та інші важливі дані для керування C: (тому що, на жаль, це важко кодовано, або тому, що ви випадково забули змінити їх налаштування). Тому ІМХО дуже ризикувати на це. Крім того, вам потрібні хороші резервні копії (див. Вище), тому після перевстановлення ви можете відновити резервні копії, що дасть вам такий же результат (просто безпечніше). Сучасні версії Windows вже зберігають дані користувачів у окремому каталозі (каталозі профілів користувача), тому можливе вибіркове відновлення.

Див. Також Чи буде ви встановлювати програмне забезпечення на той же розділ, що і система Windows? для отримання додаткової інформації.

Історична причина цієї практики, найімовірніше, пов'язана з експлуатаційними властивостями обертових магнітних жорстких дисків. Область на спінінг-дисках з найвищою послідовною швидкістю доступу - це найвіддаленіші сектори (біля початку приводу).

Якщо ви використовуєте весь накопичувач для вашої операційної системи, рано чи пізно (через оновлення тощо) ваші ОС файли будуть розповсюджені по всій поверхні диска. Отже, щоб переконатися, що файли ОС фізично перебувають у найшвидшій області диска, ви створили невеликий системний розділ на початку диска, а решту диска розповсюдите на скільки завгодно розділів даних.

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

Ця практика втратила всі свої причини з появою SSD-накопичувача.

Чи є причина зберегти основний розділ / диск Windows: малий?

Ось кілька причин для цього:

1. Усі системні файли та сама ОС знаходяться на первинному розділі. Краще тримати ці файли відокремленими від іншого програмного забезпечення, особистих даних та файлів, просто тому, що постійне втручання у завантажуваний розділ та змішування файлів там може іноді призвести до помилок, як-от випадкове видалення системних файлів чи папок. Організація важлива. Ось чому розмір основного розділу низький - відштовхувати користувачів від скидання всіх своїх даних туди.
2. Резервне копіювання - це набагато простіше, швидше та ефективніше створити резервну копію та відновити менший розділ, ніж більший, залежно від призначення системи. Як зазначає @computercarguy в коментарях, краще створити резервну копію певних папок і файлів, ніж створити резервну копію цілого розділу, якщо це не потрібно.
3. Однак це може покращити продуктивність ледь не помітним чином. У файлових системах NTFS є так звані основні таблиці файлів на кожному розділі, і вони містять метадані про всі файли на розділі:

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

Це може ввести перевагу, хоч і непомітно, тому це можна ігнорувати, оскільки це насправді не має значення. @ WooShell в відповідь більше відноситься до питання продуктивності, незважаючи на те, що до сих пір є пренебрежимо.

Ще одне, що слід зазначити , що у випадку наявності SSD + HDD, краще зберігати вашу ОС на SSD та всі ваші особисті файли / дані на жорсткому диску. Вам, швидше за все, не знадобиться підвищення продуктивності від наявності SSD для більшості ваших особистих файлів і твердотільних накопичувачів споживчого рівня, як правило, у них мало місця, тому ви краще не намагайтеся заповнити його особистими файлами .

Чи може хтось пояснити, чому ця практика робиться і чи вона все ще діє?

Описано деякі причини, чому це робиться. І так, вона все ще діє, хоча і не є хорошою практикою, як здається. Найбільш помітними недоліками є те, що кінцевим користувачам доведеться відслідковувати, де програми пропонують встановити свої файли та змінити це місце (можливо, під час майже будь-якої інсталяції програмного забезпечення, особливо якщо встановлена ​​експертна / розширена установка), тому завантажувальний розділ не буде ' t заповнити, оскільки ОС потрібно оновлювати час від часу, і ще один недолік полягає в тому, що при копіюванні файлів з одного розділу в інший він фактично потребує їх копіювання, тоді як якщо вони були в одному розділі, він просто оновлює MFT і метадані, не потрібно записувати цілі файли знову.

На жаль, деякі з них можуть створити більше проблем:

1. Це дійсно збільшує складність конструкції, що робить важче та більш трудомістким управління.
2. Деякі програми все ще записують файли / метадані в системний розділ (асоціації файлів, контекстні меню тощо), навіть якщо вони встановлені в іншому розділі, тому це ускладнює резервне копіювання та може ввести помилки при синхронізації між розділами. (завдяки коментарю @ Bob)

Щоб уникнути виниклої проблеми, вам потрібно:

1. Завжди намагайтеся встановити програми на інші розділи (змініть місце установки за замовчуванням).
2. Не забудьте встановити у вашому завантажувальному розділі лише важливе програмне забезпечення. Інше не так потрібне і неважливе програмне забезпечення має зберігатися поза ним.

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

Примітка. І, як ви вже згадували про себе, він зберігає дані, що знаходяться в окремих розділах, у разі, якщо виникла помилка завантажувального розділу.

Я розробник програмного забезпечення, але також витрачав час на "регулярну" роботу в галузі інформаційних технологій. Зазвичай я зберігаю ОС і програми на диску C :, а мої особисті файли на диску D :. Вони не обов'язково повинні бути окремими фізичними накопичувачами, але в даний час я використовую порівняно невеликий SSD як мій «системний» диск (C :) і «традиційний» диск (тобто з обертовими магнітними пластинами) як мій «дім» заїхати (D :).

Усі файлові системи підлягають фрагментації. Що стосується SSD, це в основному не проблема, але це все ще проблема з традиційними дисководами.

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

Зберігаючи мої особисті файли на окремому томі, я виявив:

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

Я спостерігав це на кількох поколіннях ПК, з декількома версіями Windows.

(Як зазначив коментатор, це також прагне полегшити створення резервних копій.)

Слід зазначити, що інструменти розробки, які я використовую, як правило, генерують велику кількість тимчасових файлів, які, здається, істотно сприяють проблемі фрагментації. Тож гострота цього питання буде залежати від програмного забезпечення, яке ви використовуєте; ви можете не помітити різниці або стільки ж однієї. (Але є й інші види діяльності, наприклад, композиція та редагування відео / аудіо, які інтенсивно вводяться / виходять, і залежно від програмного забезпечення, що використовується, можуть створювати велику кількість тимчасових / проміжних файлів. Моя думка, не пишіть це виключено як щось, що впливає лише на один клас користувачів.)

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

Ще одна примітка: якщо ви підтримуєте два окремих томи на традиційному накопичувачі, можливо, ви захочете налаштувати файл сторінки на D: том. З причин, описаних у відповіді WooShell, це скоротить час пошуку при написанні у файл сторінки.

Коротка відповідь: Більше.

На моєму досвіді (20 років роботи адміністратора ІТ), основна причина такої практики (інші перелічені нижче) полягає в тому, що користувачі в основному не довіряли Windows своїм даних та місця на жорсткому диску.

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

• Є багато продуктів, в тому числі від Microsoft, які не видаляють чисто та / або викликають проблеми сумісності та стабільності (найвизначнішим проявом є залишки файлів та записи реєстру навколо та DLL Hellу всіх його втіленнях). Багато файлів, створених ОС, не видаляються згодом (журнали, оновлення Windows тощо), що призводить до того, що ОС забирає все більше місця з часом. В епоху Windows 95 і навіть XP порада йшла далеко не так, як пропонувати чисту перевстановлення ОС раз за часом. Перевстановлення ОС вимагало можливості гарантувати витирання ОС та її розділу (також очищення будь-яких фальшивих даних у файловій системі) - неможливо без кількох розділів. І розділити накопичувач без втрати даних можливо лише за допомогою спеціалізованих програм (які можуть мати власні неприємні сюрпризи, такі як накопичення та залишення даних у непридатному стані при зіткненні з поганим сектором). Різні програми "очищення" полегшували проблему, але їх логіка базувалася на зворотному проектуванні та спостережуваній поведінці,RegCleanсама утиліта MS була вимкнена після випуску Office 2007, який порушив припущення про реєстр, на якому він базувався). Той факт, що багато програм зберігають свої дані у довільних місцях, ще більше ускладнює поділ даних користувача та ОС, змушуючи користувачів також встановлювати програми за межами ієрархії ОС.
  • Корпорація Майкрософт випробувала ряд способів підвищення стабільності з різним ступенем успіху ( спільні DLL , захист файлів Windows та його наступник TrustedInstaller, підсистема Side-by-side , окремий сховище для .NET модулів зі структурою зберігання, що запобігає конфліктам версій та постачальників. ). Останні версії Windows Installer навіть мають рудиментарну перевірку залежності (можливо, останній головний менеджер пакунків, який загалом використовується для включення цієї функції).
  • Що стосується відповідності стороннім програмним забезпеченням найкращим практикам, вони маневрували між підтриманням сумісності з неохайним написаним, але достатньо використовуваним програмним забезпеченням (інакше його користувачі не перейдуть на нову версію Windows) - що призведе до вражаючої кількості недоліки та обхідні проблеми в ОС, включаючи недокументовану поведінку API, виправлення в реальному часі сторонніх програм для виправлення в них помилок та декілька рівнів віртуалізації реєстру та файлової системи - і між примушенням сторонніх постачальників до дотримання таких заходів, як логотип сертифікації програма та програма для підписання драйверів (обов'язкове, починаючи з Vista).
• Дані користувача, поховані під довгим маршрутом під профілем користувача, зробили незручним для перегляду та вказівки шляхів до нього. Шляхи також використовували довгі імена , мали пробіли (поле командних оболонок скрізь) та національні символи (головна проблема для мов програмування, за винятком дуже недавніх, які мають всебічну підтримку Unicode) і були специфічними для локального (!) Та недоступними без доступу winapi (!!) (вбивство будь-яких зусиль з інтернаціоналізації в сценаріях), і це теж не допомогло.
  Тож наявність ваших даних у кореневому режимі окремого диска розглядалася як зручніша структура даних, ніж та, що надала Windows.
  • Це було виправлено лише в останніх випусках Windows. Самі шляхи були виправлені у Vista, ущільнюючи довгі імена, усуваючи пробіли та локалізовані імена. Проблема перегляду була виправлена ​​в Win7, яка забезпечила записи в меню "Пуск" як для кореня профілю користувача, так і для більшості інших каталогів під ним і таких речей, як стійкі папки "Улюблені" у діалогових вікнах вибору файлів, з розумними типовими параметрами на кшталт Downloads, щоб врятувати необхідність перегляду. для них щоразу.
• Загалом, зусилля МС дали згодом плоди. Поза тим, як Win7, ОС, фондове та стороннє програмне забезпечення, включаючи утиліти для очищення, є стабільними та добре сприйнятими, а жорсткі диски досить великими, щоб ОС не потребувала перевстановлення протягом усього життя типової робочої станції. І ієрархія запасів є достатньо зручною та доступною, щоб реально прийняти та використовувати її у щоденній практиці.

Вторинні причини:

• Раннє програмне забезпечення (підтримка файлової системи та розділів у BIOS та ОС) відставала від жорстких дисків для підтримки великого обсягу даних, що вимагало розщеплення жорсткого диска на частини, щоб мати можливість використовувати повну потужність.
  • В першу чергу це було проблемою в DOS та Windows 95 разів. З появою FAT32 (Windows 98) та NTFS (Windows NT 3.1) ця проблема на даний час була вирішена значною мірою.
  • Бар'єр 2TB, який з’явився нещодавно, був виправлений останнім поколінням файлових систем ( ext4 та останніх версій NTFS ), GPT та 4k дисків .
• Різні спроби оптимізації продуктивності. Обертові жорсткі диски трохи (приблизно в 1,5 рази) швидші при зчитуванні даних із зовнішніх треків (які відображаються у початкові сектори), ніж із внутрішніх, що пропонує розміщення файлів, які часто отримують доступ, як бібліотеки ОС та файли сторінок біля початку диска.
  • Оскільки користувачеві дані також доступні дуже часто, а перестановка голови має ще більший вплив на продуктивність, за межами дуже конкретних навантажень, покращення використання в реальному житті в кращому випадку є незначним.
• Кілька фізичних дисків. Це нетипова настройка для робочої станції, оскільки сучасний жорсткий диск часто досить великий, а ноутбуки навіть не мають місця для другого жорсткого диска. Більшість, якщо не всі станції, які я бачив за допомогою цього налаштування, - це настільні комп’ютери, які (повторно) використовують старі жорсткі диски, які все ще працюють та додають потрібний розмір - в іншому випадку слід використовувати або RAID, або один з накопичувачів. створити резервні копії та не бути в регулярному використанні.
  • Це, мабуть, єдиний випадок, коли можна отримати реальний прибуток від розщеплення системи та даних на окремі томи: оскільки вони фізично знаходяться на різному апаратному забезпеченні, до них можна отримати доступ паралельно (якщо тільки це два накопичувачі PATA на одному кабелі) і продуктивність не має натисніть на перестановку голови при перемиканні між ними.
    • Щоб повторно використовувати структуру каталогу Windows, я зазвичай переходжу C:\Usersдо диска даних. Переміщення лише одного профілю або навіть просто Documents, Downloadsі Desktopвиявилося неповноцінним, тому що інші частини профілю Publicможуть також безконтрольно рости (див. "Налаштування окремої конфігурації та даних" нижче).
  • Хоча диски можуть бути консолідовані в розмахуючий об'єм , я не використовую і не рекомендую це, оскільки "Динамічні томи" є власною технологією, з якою сторонні інструменти мають проблеми з роботою, і якщо будь-який з накопичувачів виходить з ладу, весь том втрачається.
• M.2 SSD + HDD.
  • У цьому випадку я раджу використовувати SSD виключно в якості кешу: таким чином ви отримуєте перевагу SSD для всього масиву даних, а не лише якусь довільну його частину, а те, що прискорюється, автоматично визначається тим, що ви насправді доступ на практиці.
  • У будь-якому випадку, це налаштування у ноутбуці поступається лише одному SSD, тому що жорсткі диски також не мають толерантності до зовнішнього удару та вібрації, що є дуже реальним явищем для ноутбуків.
• Подвійні сценарії завантаження. Як правило, дві ОС не можуть співіснувати в одному розділі. Це єдиний мені відомий сценарій, який вимагає декількох розділів на робочій станції. І використовуйте випадки для цього в будь-якому випадку зникаючі рідко, тому що кожна робоча станція зараз достатньо потужна для роботи віртуальних машин.
• На серверах існує ряд інших дійсних сценаріїв, але жоден з них не стосується домену Super User.
  • Наприклад, можна відокремити стійкі дані (програми та конфігурації) від зміни даних (дані програми та журнали), щоб уникнути невдалої програми порушити всю систему. Існують також різні особливі потреби (наприклад, у вбудованій системі, постійні дані часто перебувають на EEPROM під час роботи даних на диску RAM). Ієрархічний стандарт файлової системи Linux добре піддається налаштуванням подібного роду.

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

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

Як йдеться у відповіді WooShell, нижчі логічні сектори на диску (поза пластиною), як правило, найшвидші. Мої велоцирапторні накопичувачі потужністю 1 Тб починаються зі швидкістю 215 МБ / с, але у зовнішніх секторах падають до 125 МБ / с, на 40% падіння. А це 2,5-дюймовий привід для дисків, тому більшість 3,5-дюймових дисків, як правило, спостерігають все більші падіння продуктивності, що перевищують 50% . Це є основною причиною того, що основний розділ залишається малим, але він застосовується лише там, де розділ невеликий щодо розміру диска.

Іншою основною причиною збереження розділу був малим, якщо ви використовували FAT32 як файлову систему, яка не підтримувала розділи розміром більше 32 Гб. Якщо ви використовували NTFS, до Windows 2000 підтримувались розділи до 2 Тб, то до 256 ТБ.

Якщо ваш розділ був занадто малим щодо кількості даних, які були б записані, його легше роздробити, а складніше дефрагментувати. З вас може просто вичерпатися місця, як те, що трапилося з вами. Якщо у вас було занадто багато файлів відносно розмірів розділів та кластерів, керування таблицею файлів може бути проблематичним, і це може вплинути на продуктивність. Якщо ви використовуєте динамічні об'єми для надмірності, збереження надлишкових обсягів, наскільки це необхідно, заощадить місце на інших дисках.

Сьогодні все по-іншому, у сховищі клієнтів переважають флеш-накопичувачі або магнітні накопичувачі, прискорені спалахом. Зберігання, як правило, багате, і до нього можна легко додати більше робочої станції, тоді як за PATA днів у вас, можливо, виникло лише одне невикористане з'єднання диска для додаткових пристроїв зберігання даних.

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

Недоліком є ​​те, що є невикористаний простір, але продуктивність збільшується більше, ніж компенсує, і якщо мені потрібно більше місця, я додаю більше накопичувачів. C: містить операційну систему та часто використовувані програми. P: містить менш розповсюджені програми та являє собою SSD на 128 ГБ із нижчим ступенем довговічності запису, ніж C :. T: знаходиться на меншому SLC SSD і містить тимчасові файли користувачів та операційної системи, включаючи кеш браузера. Відео та аудіофайли зберігаються на магнітному сховищі, як і зображення, резервні копії та архівовані дані на віртуальній машині, вони, як правило, мають розмір кластера 16 КБ або більші, і при читанні / записі переважає послідовний доступ. Я запускаю дефрагвацію лише раз на рік на розділах з високою гучністю запису, і це займає близько 10 хвилин, щоб виконати всю систему.

У мого ноутбука є лише один 128 ГБ SSD та інший випадок використання, тому я не можу зробити те саме, але все одно розділяюсь на 3 розділи, C: (80 ГБ і програми), T: (8 ГБ темп) і F: ( Користувальницькі файли на 24 ГБ), що добре допомагає контролювати фрагментацію, не витрачаючи місця, і ноутбук буде замінено задовго до того, як у мене вичерпається місце. Це також значно полегшує резервне копіювання, оскільки F: містить єдині важливі дані, які регулярно змінюються.

Раніше я робив якісь ІТ-роботи, і ось що я знаю і пам’ятаю.

У минулому, як говорили інші, було справжньою користю мати невеликий розділ С на початку диска. Навіть сьогодні в деяких ноутбуках нижнього кінця це все-таки може бути правдою. По суті, маючи менший розділ, ви маєте меншу фрагментацію, і, зберігаючи його на початку диска, ви краще шукати і таким чином читати рази. Це діє і сьогодні для ноутбуків (як правило) і повільних "зелених" жорстких дисків.

Ще однією великою перевагою, яку я досі користуюсь, є наявність "даних" та "os" на окремих дисках, або якщо я не можу керувати цими розділами. Немає реального збільшення швидкості при використанні SSD або навіть більш швидких магнітних накопичувачів, але існує величезна опція "легкого виправлення", коли ОС в кінцевому підсумку резервується. Просто поміняйте диск або перегляньте цей розділ. Дані користувача недоторкані. Якщо правильно налаштовано, перезавантаження між приводом D: та "Роумінг-профілями" - це 5-хвилинна проблема. Це робить його хорошим кроком для технологій першого рівня.

Ось одна причина, але я не вважаю, що це поважна причина для сучасних (сучасних) комп’ютерів.

Це повертається до Windows 95/98 та XT. Це, мабуть, не стосується Vista та пізніших версій, але це обмеження обладнання, тому для запуску нової ОС на старому апаратному забезпеченні все-таки доведеться боротися з обмеженням.

Я вважаю, що обмеження було 2gb, але раніше могло бути обмеження на 1gb (або, можливо, інші).

Проблема полягала в такому: розділ BOOT повинен був знаходитись у межах перших 2 Гб (можливо, на 1 Гбіт раніше) фізичного простору на диску. Можливо, що 1) СТАРТ розділу BOOT повинен був знаходитись у межах межі, або, 2) ВСІЙ завантажувальний розділ повинен бути в межах межі. Можливо, що в різний час застосовувався кожен із цих випадків, але якщо застосовувався номер 2, це, ймовірно, було недовговічним, тому я вважаю, що це №1.

Отже, з №1, СТАРТ розділу BOOT повинен був знаходитися в межах перших 2 Гб фізичного простору. Це не виключає створення 1 великого розділу для Boot / OS. Але проблемою було подвійне / багатозавантажене завантаження. Якщо здавалося, що коли-небудь можна буде захотіти подвійне / багатозавантажувальний привід, під зоною 2 Гб повинен бути вільний простір для створення інших завантажувальних розділів на диску. Оскільки під час встановлення може бути невідомо, чи коли-небудь потрібен буде інший завантажувальний розділ, скажімо, Linix, або якийсь завантажувальний налагодження / усунення несправностей / відновлення розділу, його часто рекомендували (і часто, не знаючи чому), встановлювати на "малий "ОС для завантаження ОС.

Мені цікаво, чи був ваш десятиліття ІТ-відділ стурбований резервними копіями. Оскільки C: це завантажувальний / ОС-розділ, типовим буде використання певного типу резервного копіювання зображень, але для розділу даних / програми можна використовувати інкрементальний файл + резервне копіювання папок. Скорочення простору, що використовується в розділі C:, зменшить час і простір, необхідний для резервного копіювання системи.

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

Я залишаю цей розділ у своїй відповіді через коментарі нижче.

Оскільки в моїй системі є багатозавантаження, перезавантаження в іншу ОС робить резервне копіювання розділів даних / програми більш простими, оскільки немає ніякої активності на розділах (-ях) під час їх резервного копіювання. Я написав просту програму резервного копіювання, яка робить папку + копіювання файлів разом із інформацією про безпеку та повторний аналіз, але це не зовсім працює для Win 7 або Win 10 розділів ОС, тому я використовую резервну копію зображень системи для C ;, Win 7 та виграти 10 ОС.

Ні, не з Windows та його основними програмними наборами наполягають на зв’язках із Системою: незважаючи на встановлення їх у програмах:. (Це необхідність у створенні більшості ОС). Дані: об'єм має сенс, але окремий знімний диск для ваших даних (або NAS, або селективне чи додаткове резервне копіювання на такий знімний диск) має ще більше сенсу.

Розбиття розділів для систем з декількома ОС також має сенс, але кожен розділ змушує вас вибрати жорсткий верхній ліміт зберігання. Як правило, це краще з окремими накопичувачами навіть у цьому випадку.

І сьогодні віртуальні машини та хмарні диски доповнюють багато з цих варіантів.

Є одна особлива причина - використання знімків гучності.

Знімок об'єму - це резервна копія всього розділу. Після відновлення з такого роду резервного копіювання ви переписуєте весь розділ, ефективно відкочуючи систему до попереднього стану.

Системний адміністратор може регулярно створювати подібні знімки, готуючись до будь-яких помилок програмного забезпечення. Вони навіть можуть зберігати їх на іншій ділянці того ж накопичувача. Ось чому ви хочете, щоб системний розділ був порівняно невеликим.

Під час використання цієї схеми користувачам рекомендується зберігати свої дані на мережевому диску. У разі виникнення проблем із програмним забезпеченням системний адміністратор може просто повернути систему до робочого стану. Це було б надзвичайно ефективно в порівнянні з ручним дослідженням причин проблеми та її виправленням.

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

Хочу підкреслити, що найрізноманітніші фізичні диски - це, швидше за все, те, з чого почалася рекомендація. Більше півстоліття тому, коли ще не було таких речей, як перегородки, надзвичайно часто було використовувати окремий фізичний привід для системи. Основною причиною цього є фізичний рух головки та обертання приводів. Ці переваги не існують для розділів, коли фізичний диск часто використовується для інших речей.

Також зауважте, що Unix розділяє систему та дані на окремі розділи. Для цього є багато вагомих причин, як пояснено у багатьох інших відповідях, але для продуктивності окремі фізичні приводи є основним виправданням.

Причина, з якої ми робили 2 розділи, була пов’язана з вірусами. Деякі віруси використовували для перезавантаження завантажувального сектору та початку диска.

Резервні копії на комп'ютерах користувачів, які використовуються для зведення копії всієї програми на дискету. (Насправді це не резервне копіювання)

Тож коли вірус «з’їв» початок диска, зазвичай тільки систему довелося перевстановити.

І якщо б не було резервного копіювання, то відновлення даних було простіше, якщо другий розділ був недоторканим.

Тож якщо у вас є резервні копії, ця причина не є дійсною.