Refs: как работает новая файловая система windows

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

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

Storage Optimization Features in NAKIVO Backup & Replication

When it comes to protecting your virtual environment, installing a third-party data protection software is the ultimate solution. Thus, you can ensure that your business is always operational and ready to serve customers, even in case of an unexpected disaster. NAKIVO Backup & Replication is a reliable and cost-effective data protection solution which, in addition to the multiple benefits that it provides, also allows you to use the storage space in the most efficient way. To achieve storage optimization, NAKIVO Backup & Replication includes a number of advanced features described below.

Exclusion of swap files and partitions

A swap file on Windows OS and a swap partition on Linux OS are used to provide additional virtual memory and they basically function as an extension of physical RAM. Swap files and partitions help you increase the size of a computer’s physical memory by simulating it. The downside to this is that swap files have a tendency to grow over time which can eventually affect performance of your backup and replication jobs. To avoid the issue of over-cluttered storage, NAKIVO Backup & Replication can automatically exclude swap files or partitions from VM backups and replicas. This way you can reduce the size of your storage space and increase the speed of your backup and replication jobs.

Deduplication and compression

NAKIVO Backup & Replication applies deduplication and compression techniques to optimize the way that storage space is used by backups. Deduplication ensures that all duplicate copies of repeating data blocks are deleted from VM backups. This way only unique data blocks are saved to the backup repository. Moreover, NAKIVO Backup & Replication can compress each data block, thus reducing the data size. Both deduplication and data compression are enabled by default and run automatically.

Incremental jobs

Backup and replication jobs in NAKIVO Backup & Replication are incremental, meaning that after the initial full backup or replication job, all the following job runs transfer only the changed data blocks. For this purpose, VMware Changed Block Tracking (CBT) or Hyper-V Resilient Change Tracking (RCT) are used, which allow you to identify which data has changed since the last backup or replication. Running incremental jobs reduces the time spent on backup and replication jobs and decreases the network load.

Full synthetic data storage

NAKIVO Backup & Replication applies the synthetic approach to creating and storing VM backups. Due to the use of the synthetic mode, the product can identify the changed data blocks within a VM and then send them to a backup repository. In the end of a backup job run, NAKIVO Backup & Replication can create a recovery point, which is used as a reference to specific data blocks needed for restoring the VM at a particular moment in time. Synthetic backups ensure that your backups are fast and safe, the data storage space is efficiently used, and the VM at a particular moment in time can be rapidly recovered.

Deduplication appliances support

The data deduplication appliance is a special type of hardware which eliminates the duplicate copies of repeated data. NAKIVO Backup & Replication provides support for various deduplication appliances, such as NEC HYDRAstor, Data Domain, Quantum DXi, HP StoreOnce, etc. Any of those deduplication appliances can be used as a primary or a secondary backup target. Unlike the forever-incremental backup, which stores only the incremental data blocks, the new backup repository type stores VM backup chains, which include periodic full backups and incremental backup files tracked between these full backups.

The support for deduplication appliances enables you to back up VMs 53 times faster than with the traditional backup repository. Moreover, the storage space and backup operations are more easily managed with the deduplication appliance in place.

История версий и совместимость

ReFS существует в нескольких разных версиях с разной совместимостью между операционными системами. Как правило, более новые версии операционных систем могут монтировать файловые системы, созданные с помощью более ранних версий ОС. Некоторые функции могут быть несовместимы с набором функций ОС. Версия, размер кластера и другие особенности файловой системы можно узнать с помощью команды fsutil fsinfo refsinfo volumename.

• 1.1: Оригинальная версия, появившаяся в Windows Server 2012.
• 1.2: Использовалась по умолчанию для форматирования в Windows 8.1, Windows 10 (1507—1607), Windows Server 2012 R2 и при указании ReFSv1 в Windows Server 2016. Можно использовать альтернативные потоки данных на Windows Server 2012 R2.
• 9.2: Могла быть использована для форматирования в Windows 10 Technical Preview build 9841 — 9860, а также в Windows Server 2016 TP1. Не может быть смонтирована в Windows 10 Build 9879 и Windows Server 2016 R2 или выше.
• 11.2: Могла быть использована для форматирования в Windows 10 Technical Preview build 9879. Не может быть смонтирована в сборке 9926 и выше.
• 12.2: Могла быть использована для форматирования в Windows 10 Technical Preview build 9926. Не может быть смонтирована в сборке 10041 и выше.
• 22.2: Могла быть использована для форматирования в Windows 10 Technical Preview build 10049 и более ранних сборках. Не может быть смонтирована в сборке 10061 и выше.
• 2.0: Использовалась по умолчанию для форматирования в Windows Server 2016 TP2 и TP3. Не может быть смонтирована в Windows 10 Build 10130 и выше, а также в Windows Server 2016 TP4 и выше.
• 3.0: Использовалась по умолчанию для форматирования в Windows Server 2016 TP4 и TP5.
• 3.1: Использовалась по умолчанию для форматирования в Windows Server 2016 RTM.
• 3.2: Использовалась по умолчанию для форматирования в Windows 10 (1703) и Windows Server Insider Preview build 16237. Может быть отформатирован в Windows 10 Insider Preview 15002 или новее (по умолчанию стала использоваться в сборках между 15002 и 15019). В серверной редакции поддерживается дедупликация.
• 3.3: Использовалась по умолчанию для форматирования в Windows 10 Enterprise (1709) (возможность создания дисков с файловой системой ReFS была удалена из Windows 10 в редакциях Home и Pro в сборке 16226, осталось только поддержка чтения/записи.) и Windows Server (1709) (начиная с Windows 10 Enterprise Insider Preview build 16257 и Windows Server Insider Preview build 16257).
• 3.4: Используется по умолчанию для форматирования в Windows 10 Enterprise v1803 – v1809 и Windows Server 2019 v1803 – v1809.

Примечания:

1: В журнале событий записывается следующее сообщение: ‘Том «?:» был смонтирован в старой версии Windows. Некоторые функции могут быть недоступны.’

2: Windows обновит его до версии 3.2, когда для тома будет разрешена запись.

3: Windows обновит его до версии 3.3, когда для тома будет разрешена запись.

4: Windows обновит его до версии 3.4, когда для тома будет разрешена запись.

5: Windows обновит его до версии 3.1, когда для тома будет разрешена запись.

Как форматировать диск или раздел в ReFS

Допустим, пользователь наплевал на недостатки и недоработки новинки. Бог с вами, друзья, приступим к разбору инструкции по форматированию раздела в ReFS. Подскажу одну вещь, если вдруг случится неприятность и раздел откажет, для восстановления можно использовать инструмент R-Studio.

Это интересно:

Как форматировать из FAT32 в NTFS без потери данных Какой размер кластера выбрать во время форматирования

Для форматирования достаточно проделать следующую процедуру:

1. Открываем «Этот компьютер» и нажимаем правой кнопкой мышки по нужному разделу;
2. В контекстном меню жмём пункт «Форматировать»;
3. В открывшемся окне в поле «Файловая система» находим REFS;
4. Нажимаем кнопку «Начать» и ждём.

То же самое можно проделать, используя командую строку, где поочередно надо вводить такие команды:

1. diskpart – утилита для работы с дисками;
2. lis vol – отобразить все разделы компьютера;
3. sel vol 3 – где 3 номер нужного тома;
4. format fs=refs – форматирование в нужную файловую систему.

Поддержка операционными системами

Спецификации файловой системы NTFS закрыты. Это создаёт определённые трудности при реализации её поддержки в продуктах, не принадлежащих фирме Microsoft, например, разработчикам драйверов для свободных операционных систем приходится заниматься обратной разработкой файловой системы NTFS.

В данный момент полноценная поддержка NTFS присутствует только в ОС семейства Windows NT от фирмы Microsoft. Существующие средства доступа к разделам NTFS для других ОС перечислены ниже.

MS-DOS

Драйвер «NTFSDOS» от Марка Руссиновича (англ. Mark Russinovich). Стандартная версия поддерживает чтение разделов NTFS. Версия «Professional» поддерживает запись на разделы NTFS. С июля 2006 года права на утилиты Марка Руссиновича принадлежат фирме Microsoft. На сайте фирмы Microsoft информации об этом продукте нет, но его без труда можно найти в сети.

Windows 9x

Драйвер «NTFS for Windows 98» от Марка Руссиновича. Поддерживает чтение с разделов NTFS. Для записи можно использовать драйвер DOS. На сайте фирмы Microsoft информация об этом драйвере отсутствует, но его легко можно отыскать на сторонних сайтах.

Linux

Проект «Linux-NTFS». Включает модуль ядра и набор утилит для выполнения различных операций с файловой системой NTFS (проверка целостности, восстановление удалённых файлов, изменение размера и др.). Именно этот драйвер включается в ядро Linux ещё с версии 2.2 (с тех пор он был практически полностью переписан). Модулем ядра поддерживается практически только чтение; запись возможна лишь в существующие файлы без изменения их размера. Недавно в рамках проекта появилась утилита ntfsmount, использующая FUSE и позволяющая монтировать разделы NTFS с возможностью записи (с некоторыми ограничениями). Это был первый полностью свободный продукт, имеющий такую возможность.

Проект «NTFS-3G». Возник как ответвление от проекта «Linux-NTFS». Отличается более полной поддержкой записи на разделы NTFS. 21 февраля 2007 года была выпущена версия 1.0, названная стабильной. Обеспечивает высокий уровень надёжности и производительности. В настоящее время проект активно развивается.

Проект «Captive NTFS» (). Создавался как «обёртка» для использования оригинального драйвера из ОС Windows NT в ОС Linux. Запись поддерживается, но драйвер работает крайне медленно и имеет некоторые технические ограничения. На официальном сайте проекта помещено объявление о прекращении разработки.

Драйвер «NTFS for Linux» от фирмы Paragon Software. Драйвер поддерживает чтение и запись с NTFS. Кроме драйвера проект поставляет ряд утилит для создания файловой системы NTFS и выполнения некоторых операций с разделами NTFS. Доступен бесплатно для домашних пользователей.

OpenSolaris/Solaris

Проект «NTFS File System Reader (недоступная ссылка)». Поддерживает чтение с NTFS.

Проект «NTFS-3G». Необходимо установить дополнительные пакеты.

BeOS-совместимые операционные системы

Для операционных систем BeOS, Zeta и Haiku существуют следующие проекты.

Системный драйвер. Поддерживает только чтение с NTFS.

Экспериментальный драйвер. Поддерживает чтение и запись с NTFS.

KolibriOS

Драйвер, поставляемый в составе ОС KolibriOS начиная с версии 0.6.5, написан на языке ассемблера, поддерживает чтение с разделов NTFS и запуска программ.

ReactOS

Реализована поддержка NTFS «на чтение» через свободный драйвер собственного производства.
Также есть экспериментальная поддержка записи,включаемая через реестр.

Mac OS X

В ОС Mac OS X встроенный драйвер NTFS по умолчанию работает в режиме чтения. После официального выхода ОС «Mac OS X 10.6 Snow Leopard» была найдена возможность включения поддержки записи на NTFS.

Драйвер «NTFS for Mac OS X» от фирмы Paragon Software.

Драйвер «NTFS-3G».

Драйвер «MacFUSE» версии 2.0.

Какая файловая система быстрее ReFS или NTFS?

ReFS разрабатывалась не для повышения производительности файловой системы по сравнению с NTFS. Microsoft сделала систему ReFS намного эффективнее в строго определённых случаях.

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

В Windows Server 2020 Microsoft улучшила ReFS, для обеспечения лучшей производительности функций виртуальной машины. Виртуальная машина Microsoft Hyper-V использует эти преимущества (теоретически, любая виртуальная машина может использовать преимущества ReFS).

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

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

ReFS также предлагает новую функцию «редкого VDL»

Практический пример использования файловых систем

Владельцы мобильных гаджетов для хранения большого объема информации используют дополнительные твердотельные накопители microSD (HC), по умолчанию отформатированные в стандарте FAT32. Это является основным препятствием для установки на них приложений и переноса данных из внутренней памяти. Чтобы решить эту проблему, необходимо создать на карточке раздел с ext3 или ext4. На него можно перенести все файловые атрибуты (включая владельца и права доступа), чтобы любое приложение могло работать так, словно запустилось из внутренней памяти.

Операционная система Windows не умеет делать на флешках больше одного раздела. С этой задачей легко справится Linux, который можно запустить, например, в виртуальной среде. Второй вариант — использование специальной  утилиты для работы с логической разметкой, такой как MiniTool Partition Wizard Free. Обнаружив на карточке дополнительный первичный раздел с ext3/ext4, приложение Андроид Link2SD и аналогичные ему предложат куда больше вариантов.

Флешки и карты памяти быстро умирают как раз из-за того, что любое изменение в FAT32 вызывает перезапись одних и тех же секторов. Гораздо лучше использовать на флеш-картах NTFS с ее устойчивой к сбоям таблицей $MFT. Небольшие файлы могут храниться прямо в главной файловой таблице, а расширения и копии записываются в разные области флеш-памяти. Благодаря индексации на NTFS поиск выполняется быстрее. Аналогичных примеров оптимизации работы с различными накопителями за счет правильного использования возможностей файловых систем существует множество.

Надеюсь, краткий обзор основных ФС поможет решить практические задачи в части правильного выбора и настройки ваших компьютерных устройств в повседневной практике.

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

Архитектуру фс можно видеть на рисунке 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 она не реализована.

Как использовать ReFS

На обычном ПК с Windows 10 вы можете использовать ReFS только через функцию «Управление дисковыми пространствами». Обязательно отформатируйте свои пространства хранения как ReFS, а не NTFS, когда будете выбирать параметр файловой системы. Вы сможете автоматически использовать функции целостности данных в файловой системе ReFS, если её выберете.

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

Функции

• Целостность метаданных с контрольными суммами.
• 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.