• Не так давно вийшла публічна бета-версія Microsoft Windows 8 Server з підтримкою анонсованої файлової системи ReFS (Resilient File System - відмовостійка файлова система), раніше відомий під кодовою назвою “Protogon”. Ця файлова система пропонується як альтернатива зарекомендувала себе роками файловій системі NTFS в сегменті систем зберігання даних на базі продуктів Microsoft, з подальшою її міграцією в область клієнтських систем.
    Метою даної статті є поверхневе опис структури файлової системи, її переваг і недоліків, а також аналіз її архітектури з точки зору збереження цілісності даних і перспектив відновлення даних, у разі пошкодження або видалення користувачем. Стаття також розкриває дослідження архітектурних особливостей файлової системи та її потенційну ефективність.
    Windows Server 8 Beta
    Варіант файлової системи, доступний у даній версії операційної системи, має підтримку кластерів даних розміром тільки 64КБ і кластерів метаданих розміром 16КБ. Поки не ясно, чи буде підтримка файлових систем ReFS з іншим розміром кластера: в даний час параметр «Розмір кластера» при створенні тома ReFS ігнорується і завжди приймається умалчиваемым. При форматуванні ФС єдиним доступним варіантом для вибору розміру кластеру є 64КБ. Він також є Єдиним згадуваним в блогах розробників.
    Такий розмір кластера є більш ніж достатнім для організації файлових систем будь-якого розміру з практично реалізуються, але в той же час приводить до відчутного надлишковості при зберіганні даних.
    Архітектура файлової системи
    Незважаючи на часті згадки про схожість ReFS і NTFS на високому рівні, мова йде лише про сумісність деяких структур метаданих, як то: «стандартна інформація», «ім'я файлу», сумісність зі значень деяких прапорів атрибутів і т.д. Дискова реалізація структур ReFS кардинально відрізняється від інших файлових систем Microsoft.
    Основними структурними елементами нової файлової системи є B+-дерева. Всі елементи структури файлової системи представлені однорівневими (списками) або багаторівневими B+-деревами, що дозволяє значно масштабувати практично будь-який з елементів файлової системи. Поряд з реальною 64-бітної нумерацією всіх елементів системи це виключає появу “вузьких місць” при подальшому її масштаб.
    Крім кореневої запису B+-дерева, всі інші записи мають розмір цілого блоку метаданих (у даному випадку - 16КБ); проміжні ж (адресні) вузла мають невеликий повний розмір (близько 60 байт). Тому, звичайно, потрібна невелика кількість рівнів дерева для опису навіть дуже великих структур, що досить сприятливо позначається на загальній продуктивності системи.
    Основним структурним елементом файлової системи є «Каталог», представлений у вигляді B+-дерева, ключем в якому є номер об'єкта-папки. На відміну від інших подібних файлових систем, файл в ReFS не є окремим ключовим елементом «Каталогу», а лише існує у вигляді запису в містить його папці. Можливо, саме через цю архітектурної особливості жорсткі посилання на ReFS не підтримуються.
    «Листям Каталогу» є типізовані запису. Для об'єкта-папки існують три основних типи записів: специфікатор каталогу, індексний запис і описувач вкладеного об'єкта. Усі такі записи упаковані у вигляді окремого B+-дерева, що має ідентифікатор папки; корінь дерева є листом B+-дерева «Каталогу», що дозволяє упакувати в папку практично будь-яку кількість записів. На нижньому рівні в листах B+-дерева папки знаходиться в першу чергу запис опісателя каталогу, що містить основні відомості про теку (як то: ім'я, «стандартна інформація», атрибут імені файлу і т.д.). Структури даних мають багато загального з прийнятими в NTFS, хоча і мають ряд відмінностей, основним з яких є відсутність типізованого списку іменованих атрибутів.
    Далі в каталозі слідують так звані індексні запису: короткі структури, що містять дані про елементи, що містяться в папці. Порівняно з NTFS ці записи значно коротше, що меншою мірою перевантажує тому метаданими. Останніми слідують запису елементів каталогу. Для папок ці елементи містять ім'я паки, ідентифікатор папки в «Каталозі» і структуру «стандартної інформації». Для файлів ідентифікатор відсутній, але замість цього структура містить всі основні дані про файл, включаючи корінь B+-дерева фрагментів файлу. Відповідно, файл може складатися практично з будь-якого числа фрагментів.
    На диску файли розташовуються в блоках розміром 64КБ, хоча адресуються точно так само, як і блоки метаданих (кластерами розміром 16КБ). «Резидентність» даних файлу на ReFS не підтримується, тому файл розміром 1 байт на диску займе цілий блок 64КБ, що веде до значної надмірності зберігання дрібних файлів; з іншого боку це спрощує управління вільним простором і виділення вільного місця під новий файл здійснюється значно швидше.
    Розмір метаданих порожній файлової системи становить близько 0.1% від розміру самої файлової системи (тобто близько 2ГБ на те 2ТБ). Деякі основні метадані дублюються для кращої стійкості від збоїв.
    Архітектурно завантаження з розділів ReFS можлива, але в даній редакції Windows Server вона не реалізована.
    Захищеність від збоїв
    Цілі перевірити стабільність існуючої реалізації ReFS не стояло. З точки зору ж архітектури файлової системи, вона володіє всіма необхідними інструментами для безпечного відновлення файлів навіть після серйозного збою обладнання. Частини структур метаданих містять власні ідентифікатори, що дозволяє перевірити приналежність структур; посилання на містять метадані 64-біт контрольні суми блоків, на які робиться посилання, що дозволяє оцінити цілісність прочитаного за посиланням блоку.
    При цьому варто відзначити, що контрольні суми даних користувача (умісту файлів) не враховуються. З одного боку це відключає механізм перевірки цілісності в області даних, з іншого ж боку це прискорює роботу системи за рахунок мінімального кількості змін в області метаданих.
    Будь-яка зміна структури метаданих здійснюється у два етапи: спочатку створюється нова (змінена) копія метаданих у вільному дисковому просторі, потім, у разі успіху, атомарної операцією оновлення здійснюється переклад посилання зі старої (незміненій) на нову (змінену) область метаданих. Така стратегія (Copy-on-Write (CoW) -копіювання-при запису) дозволяє обійтися без журналювання, зберігаючи автоматично цілісність даних.
    Підтвердження таких змін на диску може здійснюватися не достатньо довго, дозволяючи об'єднати кілька змін стану ФС в одне.
    Дана схема не застосовується для даних користувача, тому будь-які зміни вмісту файлу пишуться безпосередньо у файл. Видалення файлу здійснюється перестроюванням структури метаданих (з використанням CoW), що зберігає попередню версію блоку метаданих на диску. Це робить відновлення видалених файлів можливим до їх перезапису новими даними користувача.
    Надмірність зберігання даних
    У даному випадку мова йде про витрачання дискового простору за рахунок схеми зберігання даних. Для цілей тестування встановлений Windows Server був скопійований на розділ ReFS розміром 580ГБ. Розмір метаданих на порожній ФС становив близько 0.73ГБ.
    При копіюванні встановленого Windows Server на розділ з ReFS надмірність зберігання даних виросла з 0.1% на NTFS майже до 30% на ReFS. При цьому ще близько 10% надмірності додалося за рахунок метаданих. У підсумку «дані користувача» розміром 11ГБ (більше 70 тис. файлів) на NTFS з урахуванням метаданих зайняли 11.3ГБ, тоді як на ReFS ті ж дані зайняли 16.2ГБ; це означає, що надмірність зберігання даних на ReFS становить майже 50% для цього типу даних. При невеликій кількості файлів великого розміру такого ефекту, природно, не спостерігається.
    Швидкість роботи
    огляду На те, що мова йде про Beta, вимірів продуктивності ФС не проводилося. З точки ж зору архітектури ФС можна зробити дещо які висновки. При копіюванні більше 70 тис. файлів на ReFS, це створило B+-дерево «Каталогу» розміром в 4 рівня: «корінь», проміжний рівень 1, проміжний рівень 2, «листя».
    Таким чином, для пошуку атрибутів папки (за умови кешування кореня дерева) требуется 3 читання блоків по 16КБ. Для порівняння, на NTFS ця операція займе одне читання розміром 1-4КБ (за умови кешування карти розташування $MFT).
    Пошук атрибутів файлу в папці та імені файлу в папці (невелика папка в кілька записів) на ReFS зажадає ті ж 3 читання. На NTFS ж вже потрібно 2 читання за 1KB або 3-4 читання (якщо запис про файл знаходиться в нерезидентному атрибуті «індекс»). У паках більшого розміру кількість читань NTFS зростає набагато швидше, ніж кількість читань, необхідних для ReFS.
    Точно так само справи йдуть і для вмісту файлів: там, де зростання числа фрагментів файлу на NTFS призводить до перебору довгих списків, рознесених по різних фрагментів $MFT, на ReFS це здійснюється ефективним пошуком по B+-дереву.
    Висновки
    Остаточні висновки поки робити рано, але за поточною реалізації файлової системи можна бачити підтвердження початкової орієнтованості файлової системи на серверний сегмент, і, перш за все, на системи віртуалізації, СУБД і сервера архівного зберігання даних, де швидкість і надійність роботи мають першорядне значення. Основний недолік файлової системи, такий як неефективна упаковка даних на диску, зводиться нанівець на системах, що оперують великими файлами.
    СисДев Лабораторіз буде стежити за розвитком цієї файлової системи і планує включення підтримки відновлення даних з цієї файлової системи. Експериментальна підтримка ReFS бета-версії Microsoft Windows 8 Server вже успішно реалізована в продуктах UFS Explorer і доступна для закритого бета-тестування серед партнерів. Офіційний реліз інструментів для відновлення видалених файлів з ReFS, а також відновлення даних після пошкодження файлової системи у результаті збоїв обладнання, планується трохи раніше або одночасно з виходом релізу Microsoft Windows 8 Server з підтримкою ReFS.
    Версія від 16.03.2012. За матеріалами СисДев Лабораторіз