Надійність дискової системи nt

Дякую вам за підтримку!

Частина 4. Журналювання NTFS

журнальованою операції

Перш за все, хотілося б розповісти про те, які саме операції журналіруются. Цілком очевидно, що повний undo-файл, здатний відкотити абсолютно всі операції, абсолютно неможливий як з точки зору швидкодії, так і з точки зору здорового глузду. Так, таке журнал дало б можливість відновити більшу кількість даних - наприклад, при здійсненні перезапису трьох мегабайт в середині файлу ми могли б спочатку зберегти нові дані в балці, потім переписати туди ж попередні три мегабайта файлу, і вже тільки потім здійснювати операції з реальними даними . Такий підхід гарантував би повну визначеність з долею інформації - ми завжди змогли б зрозуміти, яка частина даних вже записалася на диск, а якась знаходиться в початковому, що не оновленому стані. Він має всього один скромний недолік - невелика накладочка за швидкодією: для запису на диск трьох мегабайт ми змушені будемо здійснити різноманітні дискові операції на обсяг в три рази більший - дев'ять мегабайт. Так, повне журнал також застосовується - але в основному при роботі з базами даних. Якщо ви бажаєте забезпечити повне журнал будь-яких даних, ви можете поставити MS SQL або навіть Oracle, який взагалі не буде користуватися засобами будь-якої файлової системи і забезпечить збереження ваших даних у будь-яких розумних умовах. Прихильникам же повного журналювання файлової системи я можу відповісти одне: рішення скоротити швидкодію операцій записи в три рази, на мій погляд, є занадто сміливим для обов'язкового застосування - і на домашніх комп'ютерах, і на серверах.

Підхід розробників NTFS був принципово іншим. Головний девіз був, мабуть, не «надійність будь-яку ціну», а «незмінність швидкодії». Журнал роботи просто не повинно було перешкодити роботі файлової системи. Перший логічний крок - скасувати повне журнал як абсолютно неприйнятну з точки зору швидкодії. В NTFS застосовується журнал логічних структур, а не даних користувача - звідси і йде фраза, що національна безпека даних не гарантується, але, тим не менш, коректне стан самої системи буде підтримуватися. Те, що NTFS НЕ журналірует дані файлів, призводить на практиці до одного варіанту втрати даних - в тому ж гіпотетичному випадку записи трьох мегабайт, в разі збою в процесі запису ніколи вже не вдасться встановити, яка частина даних записалася, а яка залишилася незмінна. Операції, які, тим не менш, журналіруются системою - це операції зі структурами самої системи, тобто з файлами і каталогами: додавання файлів, перейменування, перенесення, створення і видалення (звільнення вільного місця). Журналіруются також і операції дефрагментації - тобто переміщення фрагментів файлів. Одним словом, все логічні операції журналіровани.

Відкладений запис і контрольні точки журналювання

Відомо, що будь-яка сучасна система для прискорення файлових операцій змушена використовувати кешування, в тому числі - кешування операцій запису. Так звана відкладена запис - принцип кешування, при якому дані, призначені для запису на диск, деякий час зберігаються в кеші і лише у вільний від інших занять час зберігаються фізично. Відкладений запис істотно підвищує ефективність дискових операцій, так як таке кешування групує безліч операцій в одну - це особливо ефективно, якщо запис проводиться в компактні ділянки диска. Ще один плюс відкладеного запису - не заважати більш потрібним операціями читання, і здійснювати запис тільки тоді, коли система вільна і їй не потрібно доступ до диска для інших потреб. Як узгодити відкладений запис з журналированием? Це досить складне питання, тому що відкладання записи робить можливим втрату тих даних, які перебували в черзі на фізичну запис і не встигли записатися на диск до збою. Найнеприємніше тут навіть не втрата даних, а то, що відбувається неузгодженість часу запису: якісь службові області можуть бути оновлені, а якісь суміжні за змістом - ще немає, так як їх оновлення могло відкладеться ще на пару секунд і не відбудуться через збій.

NTFS справляється з цими проблемами за допомогою смислового інтеграції операцій відкладеного запису і ведення журналу. При спробі почати журнальованою операцію в лог тут же записується намір - наприклад, стерти файл. Це трапляється без затримок - на цьому етапі відкладений запис не працює: це плата за присутність журналювання, якої не можна уникнути. Але от всі інші операції вже йдуть в затриманому режимі - тобто вони можуть відбутися частково (можуть ще на додачу і не в тому порядку) або не відбудуться взагалі. Єдина затримана операція, робота якої дещо відрізняється від простого запису - запис в лог про вдале завершення попередніх транзакцій, так звана контрольна точка. Через певні проміжки часу - зазвичай через кожні кілька секунд - система в обов'язковому порядку скидає абсолютно всі затримані операції на диск. Після здійснення цієї операції в журнал записується найпростіша запис - контрольна точка - яка говорить про те, що всі попередні операції виконані коректно на всіх рівнях - як на логічному, так і на фізичному.

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

Проблеми відкладеного журналювання: концепція дублювання інформації

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

Розглянемо такий випадок: ми стираємо файл. Журнал отримав запис - «файл N стирається». Потім запізнюється кешу стало завгодно здійснити спочатку фізичну позначку про те, що місце, займане файлом, звільнилося, а вже тільки потім видалити файл з фізичних структур MFT і каталогу. Припустимо, диск знаходиться в активній роботі, і на місце, що звільнилося тут же записується інший файл. У цей момент відбувається збій. Система, завантажуючись, досліджує журнал і бачить незавершену операцію «файл N стирається» - вірніше, як я вже описав вище, не незавершену, а просто операцію, контрольна точка після якої відсутній, що автоматично говорить про її незавершеності. Наступна фаза була б «відкат операції» - тобто відновлення файлу. Одна біда - місце, фізично займане файлом, містить вже інші дані.

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

Даний механізм застосовується не тільки при стирання файлу, але і при самих різних операціях: принцип журналирования - об'єкт, прибраний чи переміщений на нове місце, повинен мати можливість коректно відкотити своє «відбування» - тобто дані, на які посилаються логічні структури видаляється або переміщуваного об'єкта, необхідно ще на деякий час зарезервувати як зайняте місце (диска / каталогу). Це ще один крок NTFS до повного журнал, де специфічним журналом файлової інформації служать самі дані звільняються областей, які не знищуються фізично.

Допущення, що забезпечують надійність

Ну добре, скажете ви, все так чудово - але чому ж тоді розділи NTFS все ж летять. Зараз я спробую пояснити принципи, які призводить до того, що вищеописана модель зможе забезпечити повну восстанавливаемость логічних структур.

• Жорсткий диск, в штатному режимі, повинен записати саме те і саме туди, що і куди йому сказано було записати операційною системою. Даний принцип порушується в разі, якщо система має ненадійний шлейф, процесор, пам'ять або контролер - і це найпоширеніша причина збоїв NTFS. Вам допоможе: розігнаному процесор, дорога (якісна) пам'ять, хороша материнська плата і протокол UDMA, що забезпечує контроль і відновлення помилок на ділянці контролер-диск.
• Жорсткий диск, в разі аварії, відключення живлення або отримання від контролера сигналу «скидання» (в разі раптової перезавантаження материнської плати) зобов'язаний коректно завершити запис даних поточного фізичного сектора, якщо така проводилася на момент аварії. Проміжний стан сектора не допускається. Вам допоможуть сучасні вінчестери, які можуть здійснити дану операцію навіть у разі повного зникнення живлення - у них вистачить Буферізірованний в конденсаторах енергії, і їх логіка розрахована на коректну поведінку в разі відмови харчування під час запису.
• Диск зобов'язаний миттєво здійснити запис даних, відправлених з прапором «Не кешувати». Справа в тому, що багато сучасних диски або контролери забезпечують затриману запис. Метафайли NTFS оновлюються в режимі «писати відразу», і контролер / диск зобов'язаний виконувати цю вимогу.
• Жорсткий диск зобов'язаний забезпечити читання саме тих даних, які були записані. У разі неможливості прочитати дані видається сигнал «помилка». Диск не має права повертати помилкові дані (можливо, лише частково некоректні) без сигналу про помилку. Всі сучасні жорсткі диски мають контрольні суми секторів і жорстко дотримуються цієї логіці поведінки.

Чітке виконання цих вимог повністю гарантує надійну роботу NTFS. Структура файлової системи не буде містити суттєвих помилок навіть після збою. Деякі несуттєві помилки все ж з'являються через те, що логіка журналювання часто намагається завершити недороблені операції - наприклад, той же видалення файлу - тоді як повну надійність забезпечував би тільки безумовний відкат за все, що знаходиться після останньої контрольної точки. Малі невідповідності, що народжуються з цих спроб, відносяться до надлишкової інформації системи безпеки, не представляють ніякої реальної небезпеки для даних - вони дійсно незначні. Суть цих невідповідностей найчастіше полягає в тому, що на диску залишаються «зайві» дані про тих режимах доступів, які вже не знадобляться системі. Їх прочищення - справа суто підвищення продуктивності, як, наприклад, дефрагментація, тому їх наявність не є насправді помилкою. У разі ж виявлення серйозних, реальних, проблем драйвер сам встановить прапорець томи «брудний», що проінструктує систему перевірити тому при наступному його монтуванні.

Частина 5. Програмний RAID

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

RAID (Redundant Array of Inexpensive Disks) - надлишковий масив недорогих дисків. Технологія, яка полягає в одночасному використанні декількох дискових пристроїв для забезпечення характеристик надійності або швидкості, відсутніх у накопичувачів окремо.

Windows NT підтримує на програмному рівні три рівня RAID (так називаються стратегії роботи дискових масивів), короткі характеристики яких зведені в наступну таблицю.