Найкращі методи розподілу для SSD + звичайного HDD з багатозавантажувальним завантаженням


0

У мене є (кілька) звичайних жорстких дисків на моїй машині, і я збираюся придбати SSD, можливо, 128 Гб, для цього.

Я хотів би, щоб машина була Linux з двома завантаженнями (ядро 3.x) + Windows 7. У мого запитання є дві частини.

По-перше, припустимо, я повністю ігнорую свою поточну структуру розділів. Як мені найкраще розділити диски?

По-друге, моя поточна структура розділів має купу NTFS-розділів, один 49 Гб ext4-розділ на одному з накопичувачів та розміщення розміром 4,5 ГБ. Що б ви порадили, щоб мені не потрібно було багато перетасовувати файли та розділи?

Примітки:

  • У мене є плата Intel Z77 із технологією Smart Response , яку я хотів би використати
  • Я досить відкритий до використання LVM
  • У мене немає жорстких дисків, тому я не здогадуюся, RAID-0 / 1'і (виправте мене, якщо я помиляюся).
  • У мене є 8 ГБ оперативної пам’яті; якщо ви вважаєте, що накопичувач оперативної пам’яті є релевантним (я чув, що це пропонується), я також можу це врахувати.

Частина відповіді: використовуючи 8 ГБ всього для ОС (Windows), не використовуйте диск RAM, оскільки ви будете окупатися ще більше замінами. Особливо, якщо ви використовуєте VM.
Ян Догген

Частина відповіді (Windows): Якщо ви використовуєте всі свої 8 ГБ багато (наприклад, через велике використання VM), поставте свій файл swap на жорсткий диск, а не на SSD через обмежену кількість циклів запису. Якщо можливо, розширіть пам’ять на стільки, скільки вам потрібно, щоб запобігти використанню віртуальної пам’яті, тоді покладіть файл swap на SSD.
Ян Догген

Відповіді:


1

На даний момент я маю 128 ГБ SSD, а також працює і Windows, і Linux. Я розділив їх на 50:50 і ставлю операційні системи та міняти диски на SSD. Через декілька місяців я зрозумів, що в своєму домашньому довіднику є більше речей, ніж я можу зберігати, тому переніс це на інший, більший, не-SSD диск.

Рекомендована настройка розділу:

  1. 100 Мб завантажувальний привід UEFI
  2. ~ 20 ГБ Linux
  3. ~ 40 Гб Windows
  4. 2x своп оперативної пам’яті Linux
  5. 2x оперативної пам'яті Windows своп

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

Якщо ви переживаєте через обмеження циклу запису на SSD, перемістіть файл своп-темп для Windows на диск, який не є SSD. Якщо у вас є достатня кількість оперативної пам’яті (як я), ваш файл swap майже ніколи не буде використовуватися.

Оновлення: Що стосується SRT, ви можете альтернативно використовувати великий диск як основний, а SSD використовувати лише для кешування через SRT. Цей же розділ може застосовуватися і тут, можливо, залиште трохи більше місця для Windows, оскільки він, як правило, не працює на диску. Якщо у вас диск розміром більше 2 ТБ, ви обов'язково повинні завантажуватися за допомогою UEFI, що може створити біль, якщо у вас є, наприклад, SuperMicro BIOS. (Тому я і вирішив завантажуватися з SSD.)

Під час налаштування SRT зверніть увагу на режим, на який він буде встановлений. Покращений режим забезпечує більшу безпеку даних, а максимальний пропонує більшу швидкість за рахунок безпеки даних. Не використовуйте максимальний режим, якщо ви часто не перевіряли UPS, якщо ваші дані є найменш цінними.

Підсумовуючи: я виявив, що мій SSD на 128 ГБ трохи невеликий для двох ОС ', тому це може бути переконливою причиною для використання SRT. Однак сама технологія є дуже розвиненою формою RAID. У серверному світі всі побоюються втрати даних, і тому ніхто не наважується використовувати контролер RAID, який не має інструкцій щодо відновлення бездробних кісток. SRT може бути абсолютно безпечним, але я закликаю вас (абсолютно незалежно від СТО), щоб зробити резервні копії .


-1

На додаток до того, що сказав Janoszen, в Linux просто пам’ятайте, щоб перейти / home та / var до hdd, щоб мати більше місця в / home та не допускати, щоб часті записи в цих каталогах погіршували ваш ssd.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.