Добавить нас в закладки
Разделы
Счетчик
» » Создание нового поколения файловой системы для Windows: ReFS

   

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

Как показано на диаграмме выше, каталоги представлены в виде таблиц. Поскольку мы реализуем таблицы с помощью деревьев 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
D:\>format /fs:refs /q /i:disable

По умолчанию, если переключатель /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 в качестве следующей файловой системы массового применения.

Статья взята из блога Steven Sinofsky которая пришла мне на емейл.


Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.
Категория: Новости
(27-01-2012 22:07)     
Оценить новость:    
  • 0

Похожие новости Похожие новости из той же категории

Администрация сайта напоминает:
Авторы новости стараются для вас, создавая свои новости и для них ОЧЕНЬ важны ваши комментарии к новости- понравилось, не понравилось, пошла программа или проблемы, работает ссылка, или умерла, живое общение на сайте только привествуется! Уважайте труд других и своих оппонентов, не оскорбляйте и не ругайтесь в комментах.


Комментарии и отзывы

#3: bobpps (28 января 2012 13:29)   
Посетители

Гость
Спасибо!
9 комментариев | 0 публикаций| Зарегистрирован: 15.05.2007    Статус: Пользователь offline   
           Оценить коммент:  
  • Не нравится
  • 0
  • Нравится
#2: Trumen (28 января 2012 08:57)   
VIP

кэп
Видимо будет Protogon и ReFS - по крайне мере про первое то же писали и я сам видел наличие этого файла в папке windows и выкладывал ошибки, где маячил protogon.

Но может быть что protogon это чистая новая файловая система без NTFS, которую потом совместят с NTFS и получится ReFS.

Надеюсь ожидания оправдаются.

P.S. Хотелось бы видеть и измененный интерфейс (более простой и улучшенный) да же без Metro.
P.P.S. Metro мне не понравился. И пока нет простого способа отключения - правил через regedit.

--------------------
Никогда столько не лгут, как во время войны, после охоты и до выборов.
2379 комментариев | 0 публикаций| Зарегистрирован: 11.05.2009    Статус: Пользователь offline   
           Оценить коммент:  
  • Не нравится
  • 0
  • Нравится
#1: dok-14 (28 января 2012 00:09)   
VIP

Любопытный
Саблезуб - a_5 goodgood
Это круто!!!

--------------------
Следите за своими мыслями - они могут стать вашей судьбой.
62 комментария | 0 публикаций| Зарегистрирован: 10.09.2010    Статус: Пользователь offline   
           Оценить коммент:  
  • Не нравится
  • 0
  • Нравится
Информация
Вход на сайт

Яндекс цитирования Яндекс.Метрика

Copyright © 2006-2013. All rights reserved.