Создание нового поколения файловой системы для Windows: ReFS

В продолжение разговора о хранении данных хотелось бы обсудить следующее поколение файловых систем, внедряемых в Windows 8. На сегодняшний день система NTFS является самой распространенной и передовой в технологическом и функциональном отношении. Но при переосмыслении Windows — а мы сейчас работаем над Windows 8 — мы не останавливаемся на достигнутом; вот и для Windows 8 мы также внедряем заново разработанную файловую систему. В основе системы ReFS (Resilient File System — отказоустойчивая файловая система) лежит NTFS, поэтому новая система сохранила ключевые возможности совместимости, в то же время она разработана и спроектирована с учетом потребностей нового поколения технологий и сценариев хранения. В рамках Windows 8 система ReFS будет внедряться только как часть Windows Server 8, подобно тому, как мы внедряли каждую предыдущую файловую систему. Разумеется, на уровне приложения данные, хранящиеся в ReFS, будут доступны с клиентов, как и данные, хранящиеся в NTFS. Давайте все-таки не будем забывать, что в подавляющем большинстве случаев для файловых систем на ПК пока еще применяется технология NTFS.

Автором этой обширной статьи по разработке является Сурендра Верма (Surendra Verma) , руководитель по разработке в группе по работе с устройствами хранения и файловыми системами, но, как и всякий раз, свою лепту внесли и прочие специалисты. Часть статьи составлена по схеме «Вопросы и ответы».
--Стивен

P. S. Не забывайте читать нас в Твиттере — @buildwindows8, где мы изложили новости с выставки CES.  

---

В этой статье мне хотелось бы обсудить новую файловую систему для Windows. Эта файловая система, которую мы называем ReFS, изначально разрабатывалась для удовлетворения широкого перечня пользовательских требований, нынешних и будущих, для самых разных способов развертывания Windows.

Основные цели создания ReFS:

• Сохранение высокой степени совместимости с подмножеством наиболее востребованных функций NTFS наряду с выводом из употребления прочих, менее полезных, за счет сложности и габаритов системы.
• Проверка и автоматическое исправление данных. Повреждение данных может происходить по многим причинам, поэтому необходимо проверять и по возможности автоматически исправлять данные. Во избежание оборванных записей нельзя записывать метаданные на месте. Далее мы обсудим это подробнее.
• Оптимизация для экстремальной масштабируемости. Использование масштабируемых структур для всех случаев. Не станем предполагать, что алгоритмы проверки диска могут, в частности, масштабироваться до уровня всей файловой системы.
• Не рассматривайте файловую систему автономно. Предположим, в случае повреждения данных будет целесообразно изолировать неисправную часть, сохраняя доступ к остальной части тома. Это выполняется в процессе восстановления максимально возможного объема данных и без прекращения работы.
• Обеспечение полной сквозной отказоустойчивой архитектуры при использовании в сочетании с функцией «Пространства хранения», которая проектировалась и создавалась параллельно с ReFS.

Ключевые характеристики ReFS таковы (некоторые из них обеспечиваются в сочетании с функцией «Пространства хранения»):

• Целостность метаданных с контрольными суммами
• Целостные потоки, обеспечивающие целостность пользовательских данных (дополнительно)
• Размещение при записи транзакционной модели для надежных обновлений дисков (также называется «копирование при записи»)
• Крупные размеры тома, файла и каталога
• Группировка и виртуализация хранилищ упрощает создание и управление файловой системой
• Распределение данных для большей производительности (управление полосой пропускания) и резерв по отказоустойчивости
• Очистка диска в целях защиты от скрытых ошибок
• Устойчивость к повреждениям и «восстановление» с максимальной доступностью тома во всех случаях
• Общие пулы носителей для нескольких компьютеров в целях повышения отказоустойчивости и равномерности нагрузки

Кроме того, система ReFS наследует функции и семантику NTFS, включая шифрование BitLocker, списки управления доступом, журнал USN, уведомления об изменениях, символьные ссылки, точки соединения, точки подключения, точки повторной обработки, моментальные снимки томов, идентификаторов файлов и нежесткие блокировки.

И, разумеется, данные, хранящиеся в ReFS, доступны через интерфейсы API для доступа к файлам на клиентах, которые используются на любой операционной системе, имеющей доступ к нынешним томам NTFS.

Ключевые атрибуты и функции проекта

Атрибуты нашего проекта тесно связаны с нашими целями. По мере изучения этих атрибутов следует учитывать историю развития файловых систем, используемых в сотнях миллионов устройств, от миниатюрных компьютеров до крупнейших центров данных, от компактных форматов хранения до многошпиндельных устройств, от твердотельных накопителей до огромных дисков и систем хранения. В то же время доступ к файловым системам Windows возможен везде с помощью множества приложений и системного ПО. Система ReFS разработана с учетом и на основе этого. Мы не стали начинать с нуля, а переосмыслили систему NTFS в той мере и в тех аспектах, в каких это было разумно. Прежде всего, мы следуем тем же принципам практичности, которые требуются при создании крупной файловой системы — только корпорация Майкрософт работает в таких масштабах.

Повторное использование кодов и совместимость

Рассмотрим файловую систему API: в ней совместимость является самым важным и вместе с тем самым технически сложным моментом. Перезапись кода, обеспечивающего выполнение файловой системы, не приведет к нужному уровню совместимости, а внедряемые функции будут зависеть от кода приложения, синхронизации вызовов и аппаратного обеспечения. Поэтому при создании ReFS мы повторно использовали код, отвечающий за выполнение семантики файловой системы Windows. Этот код приводит в действие интерфейс файловой системы (чтение, запись, открытие, закрытие, уведомление об изменениях и т. п.), поддерживает файл в памяти и состояние тома, усиливает безопасность и поддерживает кэширование памяти и синхронизацию файловых данных. Такое повторное использование обеспечивает высокую степень совместимости с теми свойствами NTFS, которые мы станем применять и впредь.

Помимо той части, которая используется повторно, NTFS-версия базы кода использует механизм новой разработки с применением структур на дисках, таких как Основная таблица файлов (MFT), для представления файлов и каталогов. Система ReFS сочетает этот повторно используемый код с совершенно новым механизмом, в чем и заключается основная инновационность ReFS. Графически это выглядит так:

Надежные и масштабируемые дисковые структуры

Управление и поддержку дисковых структур осуществляет механизм хранения на диске. Он раскрывает универсальный интерфейс «ключ-значение», с помощью которого расположенный выше уровень управляет файлами, каталогами и т. п. Для своей собственной реализации, механизм хранения использует только деревья B+. Фактически мы применяем деревья B+ как единую общую дисковую структуру для представления всей информации на диске. Деревья можно внедрять внутри других деревьев (корень дочернего дерева хранится в строке родительского дерева). На диске деревья могут быть очень большими и многоуровневыми либо довольно компактными всего с несколькими ключами и внедренными в другую структуру. Это обеспечивает максимальную масштабируемость вверх и вниз для всех аспектов файловой системы. Применение единой структуры существенно упрощает систему и сокращает код. Интерфейс с новым механизмом включает понятие «таблиц» — это перечислимые наборы пар «ключ-значение». Большинство таблиц имеют уникальный идентификатор (он называется идентификатором объекта), который может служить ссылкой на них. Специальная таблица объектов индексирует все такие таблицы в системе.

Теперь давайте посмотрим, как с помощью таблиц создаются абстракции общих файловых систем.

Структуры файлов

Как показано на диаграмме выше, каталоги представлены в виде таблиц. Поскольку мы реализуем таблицы с помощью деревьев B+, каталоги можно эффективно масштабировать до огромного размера. Файлы реализуются в виде таблиц, внедряемых внутри строки родительского каталога, который сам является таблицей (на диаграмме выше он представлен как метаданные файла). Строки внутри таблицы метаданных файла представляют различные атрибуты файла. Расположение области данных файла представлено в виде встроенной таблицы потоков, которая является таблицей сопоставлений смещений (и контрольных сумм, как вариант). Это означает, что файлы и каталоги могут быть очень велики без влияния на производительность, что с лихвой компенсирует ограничения, имеющиеся в NTFS.

Как и ожидалось, прочие глобальные структуры внутри файловой системы, такие как списки ACL (Access Control Lists — списки управления доступом) представлены в виде таблиц, происходящих из таблицы объектов.

Распределение всего места на диске осуществляет иерархический распределитель, который представляет свободное место в виде таблиц свободных областей. С точки зрения масштабируемости бывает три вида таких таблиц: большой, средний и малый распределитель. Они различаются по степени разбиения подконтрольного им места на диске: например, средний распределитель управляет участками средней величины, выделенными большим распределителем. Это улучшает масштабируемость для алгоритмов распределения места на диске и позволяет удобным и естественным образом равномерно распределять соответствующие метаданные для лучшей производительности. Корни этих распределителей, равно как и корень таблицы объектов, доступны в хорошо известном месте на диске. Некоторые таблицы имеют собственные распределители, что предотвращает конфликты и позволяет локализовать область распределения.

В отличие от таблиц метаданных глобальных систем, записи в таблицах объектов относятся к каталогам, поскольку файлы встроены в каталоги.

Стратегия надежного обновления диска

Надежное и эффективное обновление диска — один из самых важных и сложных аспектов проектирования файловой системы. Мы потратили немало времени на оценку различных подходов. Один из подходов, которые мы рассмотрели и отвергли, — реализация файловой системы со структурой в виде журналов. Этот подход не годится для типа файловой системы общего назначения, которая требуется в Windows. В том, что касается обеспечения согласованности на диске, система NTFS опирается на журнал транзакций. Такой подход на месте обновляет метаданные на диске и попутно использует журнал для учета изменений, которые можно отменить в случае ошибок и при восстановлении после сбоя питания. Один из плюсов этого подхода состоит в том, что он сохраняет компоновку метаданных на месте, что может быть удобно для производительности при чтении. Основные минусы системы применения журналов состоят в том, что записи могут вестись беспорядочно и, что еще важнее, само обновление диска может повредить ранее записанные метаданные в случае сбоя питания при записи — эта проблема известна под названием оборванная запись.

Для наибольшей надежности и во избежание оборванных записей мы выбрали подход «размещение при записи», при котором метаданные никогда не обновляются на месте, а записываются в разных местах атомарным образом. Отчасти этот подход основан на уже давно известном понятии «механизм теневых страниц», который используется для надежного обновления структур на диске. Транзакции строятся на основе подхода «размещение при записи». Поскольку верхний уровень ReFS является производным от NTFS, новая модель транзакции легко использует уже существующую логическую схему восстановления после сбоя, которая была проверена и отлажена во многих выпусках.

Система ReFS распределяет метаданные таким образом, который позволяет сочетать записи для соответствующих частей (например, выделение для потока, атрибуты файлов, имена файлов и страницы каталогов) с помощью меньшего числа более крупных операций ввода-вывода, что просто замечательно как для дисковых, так и для флэш-решений. В то же время сохраняется должная степень непрерывности чтения. Здесь интенсивно используется иерархическая схема распределения.

Мы проводим важное тестирование, в ходе которого питание системы отключается, когда система работает с особенно высокой нагрузкой, а после повторного включения все структуры проверяются на наличие ошибок. Это тестирование — главный показатель успешности подхода. В ходе этого теста мы достигли беспрецедентного уровня надежности для файловых систем Microsoft. Полагаем, это решение станет лидером отрасли и поможет выполнить основные задачи проектирования.

Устойчивость к повреждениям диска

Как было сказано ранее, одной из задач проектирования была возможность выявлять и исправлять повреждения. Это не только обеспечивает целостность данных, но также улучшает доступность системы и интерактивную работу. Таким образом, для всех метаданных ReFS проверяется контрольная сумма на уровне страницы дерева B+, а сама контрольная сумма сохраняется независимо от страницы. Это позволяет нам выявлять все формы повреждений на диске, включая записи, которые были потеряны или сохранены не в нужном месте, а также битовый распад (ухудшение состояния данных на носителе). Кроме того, мы добавили функцию проверки контрольной суммы для содержимого файла. Когда эта функция под названием «целостные потоки» включена, система ReFS всегда записывает изменения файла в ином месте, чем изначально. Эта методика «размещение при записи» предотвращает потерю имевшихся данных из-за новых записей. Обновление контрольной суммы выполняется автоматически при записи данных, чтобы в том случае, если в ходе записи произойдет сбой питания, у нас всегда была систематически доступная для проверки версия файла и тем самым повреждения можно было бы выявлять принудительно.

Пару недель назад мы уже сообщали в блоге о пространствах хранения. Мы разрабатывали ReFS и пространства хранения как два взаимодополняющих компонента единой системы хранения. Мы делаем пространства хранения доступными для NTFS (и клиентских ПК), поскольку это очень полезно; многоуровневая архитектура поддерживает этот подход со стороны клиента, тогда как мы адаптируем ReFS для использования на клиентах, чтобы в итоге можно было применять ReFS и на клиентах, и на серверах.

Помимо улучшения производительности, пространства хранения защищают данные от частичных и полных сбоев диска за счет копий на нескольких дисках. При сбоях чтения пространства хранения могут читать измененные копии, а при сбоях записи (и в случае полной потери носителя при чтении/записи) могут прозрачно распределять данные заново. Во многих случаях сбой относится не к носителю, а возникает из-за повреждения данных либо из-за того, что записи были потеряны или сохранены не в нужном месте.

Это именно те виды сбоев, которые ReFS может выявить с помощью контрольных сумм. Когда система ReFS выявляет такой сбой, она связывается с пространствами хранения для чтения всех доступных копий данных и выбирает правильную на основании проверки контрольной суммы. Затем система сообщает пространствам хранения о необходимости восстановления поврежденных копий на основе верных копий. С точки зрения приложения все это происходит прозрачно. Если ReFS работает без зеркальных пространств хранения, нет возможности автоматически исправить повреждения. В этом случае система просто внесет событие в журнал, отметив, что было выявлено повреждение и, если это были файловые данные, чтение невозможно. О том, как это влияет на метаданные, я расскажу позже.

Контрольные суммы (64 бит) всегда включены для метаданных ReFS, и при условии, что том размещен на зеркальном пространстве хранения, автоматическое исправление тоже всегда включено. Все целостные потоки (см. ниже) защищены таким же образом. Это создает для пользователя сквозное решение с высокой степенью целостности, благодаря которому относительно ненадежное хранилище можно сделать весьма надежным.

Целостные потоки

Целостные потоки защищают содержимое файла от всех видов повреждения данных. Хотя это свойство ценно для многих сценариев, в ряде случаев оно неприменимо. Например, для некоторых приложений предпочтительно аккуратное управление хранением файлов с определенной компоновкой файлов на диске. Поскольку целостные потоки перераспределяют блоки при каждом изменении содержимого файлов, компоновка файлов слишком непредсказуема для таких приложений. Отличным примером служат системы баз данных. Такие приложения, как правило, ведут собственный учет контрольных сумм содержимого файлов и могут проверять и исправлять данные путем прямого взаимодействия с интерфейсами API пространств хранения.

Для случаев, когда требуется конкретная компоновка файлов, мы обеспечиваем механизмы и интерфейсы API для соблюдения этого условия на разных уровнях разбиения.

На самом простом уровне целостность является атрибутом файла (FILE_ATTRIBUTE_INTEGRITY_STREAM). Это также атрибут каталога. При наличии его в каталоге этот атрибут наследуется всеми файлами и каталогами, созданными внутри каталога. Для удобства можно использовать команду «Формат», чтобы указать это для корневого каталога тома при форматировании. Если применить это к корню, действие распространится по умолчанию на каждый файл и каталог в томе. Например:

 D:\>format /fs:refs /q /i:enable <volume>

D:\>format /fs:refs /q /i:disable <volume>

По умолчанию, если переключатель /i не указан, выбираемое системой поведение зависит от того, находится ли том на зеркальном пространстве. На зеркальном пространстве целостность включена, поскольку мы ожидаем, что преимущества значительно перевесят расходы. Приложения всегда могут отменить эту настройку для отдельных файлов.

Меры против «битового распада»

Как сказано выше, сочетание ReFS и пространств хранения обеспечивает высокую степень устойчивости данных при повреждениях диска и сбоях хранения. Труднее выявлять и исправлять потери данных, возникающие из-за «битового распада», когда не обнаруженные вовремя повреждения редко читаемых частей диска постепенно разрастаются. К моменту чтения и выявления повреждений они могут уже затронуть копии, либо данные могут быть утрачены из-за прочих сбоев.

Чтобы справиться с битовым распадом, мы добавили системную задачу, которая периодически очищает все метаданные и данные целостных потоков на томе ReFS, находящемся на зеркальном пространстве хранения. В ходе очистки все избыточные копии читаются и проверяются на правильность с помощью контрольных сумм ReFS. При несовпадении контрольных сумм копии с ошибками исправляются с помощью верных копий.

Файловый атрибут FILE_ATTRIBUTE_NO_SCRUB_DATA указывает, что программа очистки должна пропустить файл. Этот атрибут полезен для тех приложений, которые ведут собственный учет сведений о целостности, если разработчик приложения хочет большего контроля над тем, когда и как файлы очищаются.

Средство командной строки Integrity.exe дает обширные возможности управления политиками целостности и очистки.

Когда испробованы все варианты... наличие непрерывного тома

Мы ожидаем, что многие клиенты станут использовать ReFS в сочетании с зеркальными пространствами хранения, и тогда повреждения будут автоматически и прозрачно исправляться. Но бывают случаи, пусть и редкие, когда может быть поврежден даже том на зеркальном пространстве — например, память неисправной системы может повредить данные, которые затем могут оказаться на диске и повредить избыточные копии. Кроме того, многие клиенты могут не использовать зеркальные пространства хранения под ReFS.

Для случаев, когда том поврежден, система ReFS выполняет «восстановление» — это функция, удаляющая поврежденные данные с пространства имен в рабочем томе. Цель этой функции — предотвратить непоправимые повреждения, которые могли бы повлиять на доступность верных данных. Если, например, единый файл в каталоге был бы поврежден и не мог быть автоматически восстановлен, система ReFS удалила бы этот файл из пространства имен файловой системы, восстановив остальную часть тома. Как правило, такая операция занимает меньше секунды.

Обычно файловая система не может открыть или удалить поврежденный файл, и администратор не может ничего предпринять. Но поскольку система ReFS может восстанавливать поврежденные данные, администратор может восстановить файл из резервной копии или с помощью приложения воссоздать его без перевода файловой системы в автономный режим. Эта важная инновация избавляет нас от необходимости затратной процедуры проверки и исправления диска в автономном режиме и позволяет развертывать обширные тома данных без риска затяжных периодов автономной работы из-за повреждений.

Идеально подходит для стека хранения Windows

Мы знали, что при проектировании требуется достичь максимальной гибкости и совместимости. Мы проектировали систему ReFS так, чтобы она вписалась в стек хранения, как любая другая файловая система, чтобы оптимизировать совместимость с другими уровнями вокруг нее. Например, система может легко использовать шифрование BitLocker, списки управления доступом, журнал USN, уведомления об изменениях, символьные ссылки, точки соединения, точки подключения, точки повторной обработки, моментальные снимки томов, идентификаторов файлов и нежесткие блокировки. Мы ожидаем, что большинство фильтров файловых систем будут легко взаимодействовать с ReFS при небольшой модификации или без таковой. Наше тестирование доказало это. Например, нам удалось проверить функциональность существующего антивирусного решения Forefront.

Некоторым фильтрам, зависящим от физического формата NTFS, понадобится модификация в большей степени. Мы запустили обширную программу совместимости, в которой мы тестируем наши файловые системы совместно с антивирусами сторонних производителей, резервными копиями и прочими программами. То же самое мы делаем с системой ReFS и будем работать с нашими ключевыми партнерами над решением проблем с уже обнаруженными несовместимостями. Мы занимались этим и прежде, так что ReFS — это не первый случай.

Примечателен и такой аспект, как гибкость: хотя ReFS и пространства хранения взаимодействуют успешно, они созданы для работы независимо друг от друга. Это обеспечивает максимальную гибкость развертывания для обоих компонентов без лишних взаимных ограничений. Иными словами, подбирая соответствующий уровень надежности и производительности, можно получить готовое решение для хранения, включая развертывание ReFS с базовым хранилищем для наших партнеров.

Благодаря пространствам хранения пул носителей может совместно использоваться несколькими компьютерами, а виртуальные диски могут беспрепятственно перемещаться между ними, повышая отказоустойчивость. Архитектура, созданная нами для системы ReFS, позволяет ей воспользоваться этим преимуществом.

Использование

Мы тестировали ReFS с помощью сложного и обширного набора десятков тысяч тестов, которые разрабатывались для NTFS на протяжении свыше 20 лет. Эти тесты воссоздают, и даже в усложненном виде, условия развертываний, с которыми система может столкнуться при повышенной нагрузке, например, из-за сбоя питания или проблем с масштабируемостью или производительностью. Поэтому система ReFS готова к тестовому развертыванию в управляемой среде. Поскольку это первая версия крупной файловой системы, осторожность не помешает. Мы не характеризуем ReFS для Windows 8 как бета-версию. Новинка будет готова к выпуску тогда, когда Windows 8 выйдет из статуса «бета», ведь что может быть важнее, чем надежность данных. Итак, в отличие от любого другого аспекта системы, в данном случае обязателен консервативный подход к первоначальному развертыванию и тестированию.

Памятуя об этом, мы займемся реализацией ReFS в несколько этапов: сначала в виде системы хранения для Windows Server, затем как хранилище для клиентов и в итоге как загрузочный том. Это тот же подход, который мы применяли для новых файловых систем в прошлом.

Изначально основной целью теста будет запуск ReFS в качестве файлового сервера. Мы ожидаем, что клиенты выиграют от использования системы в качестве файлового сервера, особенно на зеркальном пространстве хранения. Мы также планируем работать с нашими партнерами в сфере хранения для интеграции системы с решениями хранения.

Завершение

Наряду с пространствами хранения, ReFS создает основу для хранения в Windows на следующие 10 лет или даже больше. Мы считаем эту систему важным шагом на пути создания современных хранилищ. И пространства хранения, и система ReFS изначально проектировались с возможностью дальнейшего развития, и мы надеемся увидеть ReFS в качестве следующей файловой системы массового применения.

-- Сурендра

Вопросы и ответы:

Почему система называется ReFS?

ReFS означает Resilient File System — «отказоустойчивая файловая система». Хотя работа по усовершенствованию ведется по многим направлениям, отказоустойчивость остается приоритетом.

Каковы предельные мощности системы ReFS?

Предельные мощности для дискового формата указаны в таблице ниже. Предельные показатели зависят от различных факторов, таких как конфигурация системы (например, объем памяти), пределы, задаваемые различными компонентами системы, а также время, требуемое для заполнения наборов данных, время создания резервных копий и т. д.

Можно ли конвертировать данные между NTFS и ReFS?

В Windows 8 нет возможности конвертировать данные на месте. Данные можно копировать. Это было преднамеренное решение в ходе проектирования, учитывая, какие сегодня размеры наборов данных и как неудобно было бы конвертировать на месте, а также учитывая вероятные изменения в архитектуре до и после конвертирования.

Можно ли выполнять загрузку с ReFS в Windows Server 8?

Нет, такая возможность не реализована и не поддерживается.

Можно ли использовать ReFS на съемных носителях или дисках?

Нет, такая возможность не реализована и не поддерживается.

Что из семантики или функций NTFS больше не поддерживается в ReFS?

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

Как насчет пространств на основе четности и ReFS?

Систему ReFS поддерживают функции отказоустойчивости, обеспечиваемые пространствами хранения. В Windows Server 8 автоматическое исправление данных выполняется только для зеркальных пространств.

Поддерживается ли кластеризация?

Поддерживается отказоустойчивая кластеризация, причем отдельные тома могут менять ресурсы при отказе. Кроме того, поддерживается совместное использование пулов носителей в кластере.

Как насчет RAID? Как использовать возможности ReFS по распределению данных, зеркальному отображению и другим формам RAID? Обеспечивает ли ReFS ту скорость чтения данных, которая нужна, например, для видеофайлов?

Система ReFS применяет имеющиеся в пространствах хранения возможности избыточности данных, в том числе распределенные зеркала и четность. Ожидается, что скорость чтения в системе ReFS будет примерно на том же уровне, что и в системе NTFS, с которой у них много общего кода. Для потоковой передачи данных это будет замечательно.

Как получилось, что ReFS не обеспечивает дедупликацию, кэширование второго уровня между DRAM и хранилищем, а также запись снимков?

Сама система ReFS не обеспечивает дедупликацию. Одним из побочных эффектов этой знакомой, подключаемой архитектуры файловой системы является то, что другие продукты для дедупликации смогут подключаться к ReFS так же, как и к NTFS.

Кэширование второго уровня не реализовано явным образом в ReFS, но клиенты могут воспользоваться решениями сторонних разработчиков.

ReFS и VSS взаимодействуют для создания снимков по тому же принципу, что NTFS в средах Windows. На текущий момент они не поддерживают запись снимков или снимки свыше 64 ТБ.