ReFS (Resilient File System)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:30, 11 января 2019.
ReFS
LogoReFS.jpg
Windows8-Protogon.png
Полное название Resilient File System
Limits
Макс. размер тома 1 йоттабайт
Макс. размер файла 16 эксабайт
Features
Признаки Да
Прозрачное сжатие Нет
Копирование и запись Да
Другие
Операционная система Windows Server 2012Windows Server 2012 R2Windows 8Windows 8.1, Windows 10, Windows Server 2016
Веб-сайт Resilient File System Overview
ReFS (англ. Resilient file system, предварительное название Protogon)  – локальная файловая система, используемая в Windows Server 2012Windows Server 2012 R2, бета-версиях Windows 8Windows 8.1. Является дальнейшим развитием NTFS. Protogon поддерживает точки повторной обработки (reparse points) – технологию, которая ранее содержалась только в файловой системе NTFS. Через точки повторной обработки реализована поддержка символьных ссылок и точек монтирования в Windows, так что Protogon также поддерживает их. По сравнению с NTFS, на август 2011 года отсутствует поддержка именованных альтернативных файловых потоков. Protogon не поддерживается Windows 7 и более ранними системами.

История

ReFS основана на NTFS и хранит совместимость по ключевым направлениям, но в то же время это совершенно другая архитектура. Некоторые фичи и семантики NTFS ликвидированы, в том числе поддержка коротких имён, ID объектов, компрессия, шифрование на уровне файлов (EFS), дисковые лимиты (квоты), потоки данных, транзакции, разрежённые файлы, расширенные атрибуты и жёсткие ссылки.

ReFS является дальнейшим развитием NTFS. ReFS поддерживает точки повторной обработки (reparse points) – технологию, которая ранее содержалась только в файловой системе NTFS. Через точки повторной обработки реализована поддержка символьных ссылок и точек монтирования в Windows, так что Protogon также поддерживает их.[Источник 1]

Функции

  • Целостность метаданных с контрольными суммами.
  • Integrity streams: метод записи данных на диск для дополнительной защиты данных при повреждении части диска.
  • Транзакционная модель "allocate on write" (copy on write)
  • * Большие лимиты на размер разделов, файлов и директорий. Размер раздела ограничен 278 байт при размере кластера 16 КБ (264 * 16 * 210), стек Windows поддерживает 264. Максимальное количество файлов в директории: 264. Максимальное количество директорий в разделе: 264.
  • Организация пулов и виртуализация для более простого создания разделов и управления файловой системой.
  • Сегментация последовательных данных (data sriping) для повышения производительности, избыточная запись для отказоустойчивости.
  • Поддержка техники чистки диска в фоновом режиме (disk scrubbing) для выявления скрытых ошибок.
  • Спасение данных вокруг повреждённого участка на диске.
  • Общие пулы хранения данных между машинами для дополнительной отказоустойчивости и балансировки нагрузки.

Цели, которые достигаются использованием данной файловой системы:

  • Сохранить максимальную совместимость с набором широко используемых фич NTFS, и в то же время избавиться от ненужных, которые только усложняют систему
  • Верификация и автоисправление данных.
  • Максимальная масштабируемость.
  • Невозможность полного отключения файловой системы за счёт изоляции сбойных участков.
  • Гибкая архитектура с использованием функции Storage Spaces, которая задумана и реализована специально для ReFS.

В дополнение, ReFS унаследует многие функции и семантики NTFS, включая шифрование BitLocker, списки контроля доступа (ACL), журнал USN, уведомления об изменениях, символьные ссылки, точки соединения (junction points), точки монтирования (mount points), точки повторной обработки (reparse points), снимки тома, ID файлов и oplock.

Конечно же, данные с ReFS будут доступны для клиентов через те же API, которые используются сегодня во всех операционных системах для доступа к разделам NTFS.[Источник 2]

Особенности

Можно выделить следующие особенности ReFS:

  • Повышенная надёжность хранения информации на диске структур (по сравнению с NTFS). B+ деревья как для метаданных, так и для содержимого файлов. Размеры файлов, томов, количество файлов в каталоге ограничены 64-битной длинной, размер файла 16 эксбибайт, размер тома в 1 йобибайт (при использовании кластеров данных размером 64 КиБ). Свободное место на диске описывается 3 отдельными иерархическими таблицами для малых, средних и больших фрагментов свободного пространства. Имена файлов и длина пути ограничена 32 кибибайтами, для их хранения используется Unicode.
  • Copy-on-write для метаданных, при которой любые транзакции файловой системы не перезаписывают старые метаданные, а записываются в новый блок и организуются в пачки. Для метаданных используются 64-битные контрольные суммы. Данные файлов могут иметь контрольную сумму в отдельном потоке (атрибут «integrity»). В случае, если содержимое файлов или метаданных не соответствует контрольным суммам, не требуется отключение файловой системы для удаления или восстановления таких данных. За счет встроенных проверок не нужно регулярного использовать утилиту проверки диска.
  • Совместимость со старыми API. Интегрируется с технологией виртуализации носителей данных Storage Spaces, которая позволяет применять зеркалирование и объединять несколько физических носителей, как в рамках одного ПК, так и через сеть. При использовании зеркалирования ReFS может обнаруживать и исправлять сбойные копии файлов в процессе data scrubbing, при котором проводится фоновая сверка контрольных сумм.
  • Не поддерживаются именованные потоки файлов, короткие имена файлов, сжатие файлов, шифрование на уровне файлов Encrypting File System, транзакции NTFS, жёсткие ссылки, extended attributes, и дисковые квоты.
  • Метаданные файловой системы всегда защищены. Контрольные суммы метаданных хранятся отдельно, что уменьшает вероятность повреждения и метаданных и контрольных сумм. При необходимости, так же можно защитить и пользовательские данные на уровне тома, папки или файла.
  • Высокая доступность. При обнаружении ошибок, которые не могут быть исправлены автоматически, специальный процесс локализует ошибку, не требуя при этом отключения тома. То есть том может находится в рабочем режиме достаточно долго. В сочетании со Storage Spaces, при обнаружении ошибок исправляет их.
  • Расширяемость. ФС будет работать как с нынешними терабайтными объёмами, так и с теми, которые будут в будущем.
  • Совместимость с различными приложениями, на пример Win32 API.
  • Обнаружение ошибок «на лету».
  • Эволюция в архитектуре (по сравнению с NTFS). Новая файловая система по сути является результатом развития старой файловой системы NTFS, а следовательно поддерживает большую часть функциональности NTFS (шифрование BitLocker, access-control lists, USN journal, change notifications, символические ссылки, junction points, mount points, reparse points, снимки тома, идентификаторы файлов, oplocks).[Источник 3]

Архитектура файловой системы

Архитектуру фс можно видеть на рисунке 1 ниже.

Рисунок 1 – Архитектура ReFS.

Несмотря на частые упоминания о схожести 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 она не реализована.[Источник 4]

Защищенность от сбоев

Цели проверить стабильность существующей реализации 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 чтения по 1КБ или 3-4 чтения (если запись о файле находится в нерезидентном атрибуте «индекс»). В паках большего размера количество чтений NTFS растет намного быстрее, чем количество чтений, требуемых для ReFS.

Точно так же дела обстоят и для содержимого файлов: там, где рост числа фрагментов файла на NTFS приводит к перебору длинных списков, разнесенных по разным фрагментам $MFT, на ReFS это осуществляется эффективным поиском по B+-дереву.[Источник 5]

Совместимость со старыми API

Совместимость со старыми API, поддержка многих особенностей NTFS, например, шифрование BitLocker, Access Control Lists, USN Journal, уведомления об изменениях, символьные ссылки, junction point, точки монтирования, reparse point, снапшоты томов, идентификаторы файлов, NTFS oplock. ReFS интегрируется с технологией виртуализации носителей данных Storage Spaces, которая позволяет применять зеркалирование и объединять несколько физических носителей, как в рамках одного ПК, так и через сеть.  При использовании зеркалирования ReFS может обнаруживать и исправлять сбойные копии файлов в процессе data scrubbing, при котором проводится фоновая сверка контрольных сумм.

NTFS  и ReFS

Многие возможности NTFS не поддерживаются в ReFS, включая именованные потоки файлов (после проверки на Windows 10 TP ADS работает с ReFS. Для поддержки ReFS нужно вносить изменения в реестр), NTFS Distributed Link Tracking (DLT), короткие имена файлов (формат 8.3), сжатие файлов, шифрование на уровне файлов Encrypting File System, транзакции NTFS, жёсткие ссылки, extended attributes, и дисковые квоты. Разреженные файлы (Sparse files) поддерживаются в RTM. В Windows Server 2012 не поддерживается загрузка с ReFS. Ввиду отсутствия поддержки именованных потоков, ReFS не может быть использована для размещения экземпляров MS SQL, включая версию 2012.[Источник 6]

Источники

  1. Подробности о файловой системе ReFS (Protogon) // habr [2006–2019]. Дата изменения: 18.01.2012. URL: https://habr.com/post/136464/ (дата обращения: 11.01.2019).
  2. Resilient file system // Центр разработки для Windows [2018]. Дата изменения: 31.05.2018. URL: https://docs.microsoft.com/ru-ru/windows/desktop/w8cookbook/resilient-file-system--refs- (дата обращения: 6.12.2018).
  3. Resilient File System (ReFS) // TechNet [2015]. Дата изменения: 31.08.2013. URL: https://social.technet.microsoft.com/wiki/ru-ru/contents/articles/12775.resilient-file-system-refs.aspx?Redirected=true (дата обращения: 6.12.2018).
  4. Файловая система ReFS изнутри // r.lab [2019]. Дата изменения: 01.01.2019. URL: https://rlab.ru/doc/refs_file_system.html (дата обращения: 11.01.2019).
  5. Файловая система ReFS изнутри // R.Lab [2018]. Дата изменения: 16.03.2012. URL: https://rlab.ru/doc/refs_file_system.html (дата обращения: 6.12.2018).
  6. Подробности о файловой системе ReFS (Protogon) // habr [2006–2018]. Дата изменения: 18.01.2012. URL: https://habr.com/post/136464/ (дата обращения: 6.12.2018).