1. Яка файлова система більше схильна до фрагментації?
2. Вибір файлової системи, спосіб розмітки і настройка
3. Розміщення файлів на жорсткому диску.
4. Дефрагментація жорстких дисків (HDD)
5. Цикли включення / вимикання / перезавантаження ПК
6. Трохи про "Кілька оптимізують твиков Windows"
7. Рекомендований контент

Яка файлова система швидше вбиває диск? Як продовжити термін служби жорсткого диска? У цій статті ми постараємося дати осудні відповіді на питання щодо вибору і розмітці файлової системи для більш продуктивної і тривалої служби HDD ...

Термін служби жорсткого диска (HDD) як і його продуктивність безпосередньо залежить від вибору файлової системи, способу її розмітки, а також зрозуміло активності і умов використання.

Яка файлова система більше схильна до фрагментації?

Всі файлові системи схильні до фрагментації, незалежно від типу використовуваної ОС - ось так от! :) Чому? Та тому, що на свіжий / порожній диск дані пишуться в кожну наступну за попередньою вільну одиницю зберігання даних - кластер (блок, зона). Згодом старі дані видаляються, а нові записуються на їх місце - наприклад ми видалили файл розміром в 5 мб., Який був розташований в середині масиву вже записаних даних, значить між даними утворилася "діра" в 5 мб., Тепер пишемо на диск файл розміром в 10 мб., який однією своєю половиною займає "дірку" в 5 мб., а під інші 5 мб. вільне місце шукається десь там. Детальніше читаємо в Дефрагментація диска .

Достовірно відомо, що ФС FAT більш схильна до фрагментації, ніж ФС NTFS. Для ОС Linux / BSD в даний час рекомендуються ФС ext4 / ufs, які мають свої механізми перешкоджають фрагментації, але не виключають її! Наприклад файлова система ext4 має механізм просторової (extent) записи файлів, що зменшує фрагментацію і підвищує продуктивність.

Для флеш-накопичувачів рекомендується exFAT (Extended FAT), але її підтримка можлива тільки в ОС сімейства Windows - іншими словами на ОС типу Linux / BSD читання даних з exFAT буде неможливим!

Вибір файлової системи, спосіб розмітки і настройка

З вибором файлової системи ми визначилися - це NTFS для Windows і ext4 / ufs для Linux / BSD. Велику роль у збільшенні терміну життя HDD грає не тільки сам тип файлової системи (FAT / NTFS / UFS etc), але і спосіб розмітки, а також тонка її налаштування.

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

В операційних системах Windows розмір кластера (зони в Minix, блоки в Unix), в файлової системі NTFS, при якому можливе стиснення, становить 512-4,096 байт і за замовчуванням при форматуванні дорівнює 512 байт, тобто 1 кластер складається з 1 сектора (в більшості дисків 1 сектор = 512 б). Якщо розмір кластера для ФС NTFS вище 4,096 байт, то стиснення файлів буде недоступне! Максимальний розмір кластера / блоку як для NTFS так і для UFS2 / FFS дорівнює 64 кб ..

Наприклад, ми маємо файлову систему отформатированную з розміром кластера за умовчанням (512 байт, 1 сектор), то при записі файлу займає більше 1-го кластера, скажімо файлу розміром 2048 б (2 КБ), магнітним голівках диска потрібно буде зробити додаткову роботу і відшукати найближчий вільний кластер на що зрозуміло витрачається час і ресурс життя диска, а також збільшується фрагментація файлів.

Таким чином, при маленькому розмірі кластера і регулярному видаленні / записи, великі файли просто кажучи "розмазуються" по всьому жорсткому диску, що зрозуміло уповільнює їх читання / запис, а також скорочує термін життя HDD. Значить бажано мати кілька розділів, під різні типи файлів, з різним розміром кластера - наприклад для зберігання мультимедіа файлів можна створити розділ з максимальним, для NTFS, розміром кластера в 64 кб., А під системний взяти стандартний розмір кластера в 512 або підняти до 1024 -2048 б.

Відзначимо, що чим більшого розміру кластер, тим менше місця займає "Master File Table" (MFT) і тим швидше працює ФС, але потрібно також мати на увазі, що кожен фай або каталог займає повністю як мінімум 1 кластер - тобто якщо ФС відформатована кластерами по 4 КБ, то при створенні порожнього текстового файлу в 0 КБ він буде фактично займати 4 КБ (один кластер), а при великій кількості порожніх файлів на ФС з кластерами в 4 КБ або більше самі напевно здогадуєтеся .., та - в файлах буде порожньо і місце на жорсткому диску швидко закінчиться!

Крім предустановочной підготовки жорсткого диска потрібно з'ясувати перелік параметрів, які регулюють поведінку / роботу файлової системи - наприклад для ФС NTFS (Windows) це NtfsAllowExtendedCharacterIn8dot3Name, NtfsDisable8dot3NameCreation, NtfsDisableLastAccessUpdate, для ФС EXT3 / EXT4 (UNIX-like) це commit = 120, noatime, nodiratime , barrier = 0, nobh, nouser_xattr і т.п ..

Розміщення файлів на жорсткому диску.

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

У самому-самому початку краще розміщувати файл підкачки, а в наступному розділі вже саму ОС - тобто під перший створюваний розділ (зазвичай завжди "C") вибілити 2-4 ГБ з максимальним розміром кластера в 64 кб, а в наступний "D" вже ставити саму ОС.

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

Дефрагментація жорстких дисків (HDD)

Майже всі речовини в помірних дозах можуть бути ліками - так і з дефрагментацією. Дефрагментація жорсткого диска тільки в разі потреби, коли результатом аналізу є повідомлення про необхідність дефрагментації, також може продовжити термін життя жорсткого диска скоротивши / упорядкувавши місце використовується файлами.

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

Часта дефрагментація "шкодить" диску HDD, скорочує термін його життя і при особливо фанатичному підході диск можна просто "зарізати"!

Цикли включення / вимикання / перезавантаження ПК

Багато сісь. адміністратори помітили закономірне відмінність термінів життя жорстких дисків (HDD) в залежності з кількістю включення / вимикання / перезавантаження ПК. Там, де ПК включався / вимикався / перезавантажувався частіше, там жорсткі диски (HDD) накривалися теж частіше, а на ПК з "аптаймом" 80-100% жорсткі диски (HDD) жили в 2-3 рази довше.

Тому для продовження терміну служби жорсткого диска бажано ПК зовсім не вимикати, а монітор встановити на відключення після 5-20 хв. простою, але в такому випадку підвищиться знос материнської плати і її компонентів, а також витрати на електроенергію. Для запобігання швидкого зносу материнської плати і її компонентів при 80-100% Аптайм бажано навколо ПК забезпечити температуру + 15 / + 20С - більше або менше не рекомендується, також бажано кожні 2-3 міс. чистити від пилу та ін ..

Трохи про "Кілька оптимізують твиков Windows"

Під ОС сімейства Windows по мережі "поневіряється" якийсь DWORD параметр ContigFileAllocSize який по ідеї повинен бути розташований в гілці реєстру HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ FileSystem і вказує в десятковій системі хв. розмір в КБ запитуваної нерозривного дискового простору під запис файлу. Іншими словами - ми пам'ятаємо що файл пишеться т.с. куди попало шматками хв. в один кластер, після запису першого шматка / кластера / блоку даних запитується місце під другий, так ось DWORD параметр ContigFileAllocSize нібито встановлює хв. розмір шматка (нерозривного дискового простору), який має знайти система перед початком запису файлу.

Зараз ми будемо руйнувати міфи про ContigFileAllocSize:

1. Цей параметр працездатний тільки для Windows 98 і згадується тільки на одній єдиній оф. сторінці http://support.microsoft.com/kb/835821/ru;
2. Значення параметра встановлюється в кілобайти, а не байт;
3. На ос Windows XP ця фіча не працює - перевірено, установкою максимально допустимого DWORD значення для ContigFileAllocSize, що дорівнювало 4294967295 (0xffffffff), при цьому система нормально завантажувалася і ніяких проблем із записом / читанням не виникало (простору було вільно 2 ГБ з 10- ти), хоча при перевищенні значення в 4,048 лякали як мінімум проблемами із записом, а то і зовсім неможливістю завантажити WindowsXP / 2000.

Тепер ще про "Кілька оптимізують твиков Windows", де відносно все того ж ContigFileAllocSize тупо копальні / пастіца ось така єресь:

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

Ось так і шириться єресь - один десь тупо здер і розіслати р лал по всій мережі, третій підхопив і пішло / поїхало ... Але, ми ж бо знаємо, що:

1. Файл пишеться в першу вільну одиницю зберігання даних, якими оперує ОС, а не "в перший-ліпший вільну ділянку величиною 512 кілобайт";
2. Операційні системи, в якості одиниці зберігання інформації, оперують кластерами (зони в Minix, блоки в Unix / Linux);
3. Кластери (зони в Minix, блоки в Unix / Linux) складаються з секторів диска, а сектора в свою чергу у різних жорстких дисків можуть мати різний розмір, але зазвичай це 512 байт.

Не хочу ображати афтор, може він просто помилково замість "512 байт" написав "512 кілобайт" і "Видно, що при такій роботі відбувається дефрагментація диска" замість "Видно, що при такій роботі відбувається фрагментація файлів", але по факту грішне з праведним реально поплутав, більш того сам DWORD параметр ContigFileAllocSize до Windows XP (швидше за все також і до 2000/7) ніякого відношення не має, який не згадується і в оф. документації до згаданої ОС і не впливає на її роботу, що перевірено досвідченим шляхом в Windows XP!

Скажу однозначно те, що в мережі дофіга шлаку і часто здавалося б на нібито авторитетних і мега відвідуваних веб-ресурсах, друкують відверту МЕГА-хрін навколо якої часто розпалюються некволі і затяжні "холівари", тому потрібно вміти фільтрувати отриману інфу інакше тупе дотримання інструкцій типу "Кілька оптимізують твиков Windows" може забезпечити раптовий "кирдик" Вашому ПК, а це вбите залізо, втрачений час, схудлий гаманець і порвані на попі волосся! :)

У нас, на відміну від деяких, тільки перевірена інфа, а хто не згоден пишіть свої аргументи в коментарі! :)

Олег Головський

Рекомендований контент

про автора

Юрист, програміст, спортсмен, бізнесмен і просто красень.

Ще статті автора