Пользователь
100,4
рейтинг
18 января 2012 в 00:35

Разработка → Подробности о файловой системе ReFS (Protogon)

В блоге разработчиков Windows 8 опубликована большая статья с описанием архитектуры новой файловой системы ReFS (Resilient File System), ранее известной под кодовым названием Protogon, которая разрабатывается для Windows Server 8, а в будущем она будет доработана и начнёт устанавливаться также на клиентских машинах Windows. Прошлая файловая система NTFS в версии 1.2 была представлена в далёком 1993 году как часть Windows NT 3.1, а к появлению Windows XP в 2001 году NTFS доросла до версии 3.1, и только тогда её начали ставить на клиентские машины. Примерно такой же путь развития ожидает ReFS.

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

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


Структура данных ReFS реализована в виде B+ деревьев

Ключевые цели ReFS

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

Ключевые функции ReFS

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

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

Конечно же, данные с ReFS будут доступны для клиентов через те же APIs, которые используются сегодня во всех операционных системах для доступа к разделам NTFS.
Анатолий Ализар @alizar
карма
743,5
рейтинг 100,4
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (47)

  • +11
    Чем же им хардлинки не угодили?
    • +1
      И грузиться с неё нельзя.
      • 0
        Это начальный превью релиз, потом все добавят.
        «we will implement ReFS in a staged evolution of the feature: first as a storage system for Windows Server, then as storage for clients, and then ultimately as a boot volume. This is the same approach we have used with new file systems in the past»
  • +14
    Они забыли добавить «iser» после RE ☺
  • +4
    У меня создалось впечатление, что это недо-ZFS для данных.
  • 0
    Печально, что опять придётся под Линукс ждать хорошей поддержки этой ФС, как уже было с NTFS. Разве что Майкрософт откроет спеки…
    • +3
      Она ещё очень и очень долгое время останется чисто серверной, так что линуксовый драйвер не так уж необходим. Опять же во время написания первых линуксовых дров для NTFS в ядре не было такой вундервафли как FUSE.
      • 0
        +100 к FUSE!!!(как же я про нее забыл)
        какие только виртуальные файловые системы на ней не реализуют. Скажем SSHFS какая прелесть!
        • 0
          Прелесть ровно до того момента, как порвется соединение.
          Наверное, у меня кривые руки, но решить проблему с тотальным зависанием в этом случае мне не удалось до сих пор…

          Но FUSE да, вещь крутая.
          • 0
            На нестабильном соединении — вообще не стоит применять виртуальные сетевые ФС, в большинстве случаев после таймаута — получите зависание.
            На таком канале поддается некоторой настройке NFS, но это тоже не панацея.
            В вашей ситуации применяю ssh для удаленного подключения к сессии screen и scp для копирования файлов в обоих направлениях. Для командных сценариев на python модуль paramiko.
          • 0
            > решить проблему с тотальным зависанием в этом случае мне не удалось до сих пор

            umount -f /mountpoint
            

            И монтируем заново, если нужно.
            • +1
              Правильнее fusermount -u.
      • 0
        Как то не тянет ReFS на серверную, в свете упрощений и выкидывания «ну совсем ненужных для сервера ФС» фич (шифрование, квоты, транзакции и т.п.). Скорее я бы сразу назвал её ФС для домашней сферы (ну и для мелкого бизнеса).
        • 0
          Читайте оригинал. Убирают только рудимент, ФС от этого функционально не пострадает
    • +1
      Что то не печалит это меня нисколечки. Возможно дело в особенностях работы и пр. деятельности. В скольких случаях использовал сегодняшний, стабильно работающий, драйвер под ntfs (ntfs-3g) вообще считаю по пальцам: притащили usb-хард расформатированный под ntfs. забрал данные с диска из под погибшей у кого то винды, убил винлокер при помощи livecd от касперского(тот что на основе gentoo сделан)… и наверно все за последние полгода.
      Согласен — тем кто работает с использованием двойной загрузки (win/lin) может и нужно = но в таком случае обычно создается раздел для обмена данными — сейчас можно и под ntfs, раньше был fat32
      Еще момент: обычно внедрение новой fs у microsoft идет весьма неспешно(как было уже с ntfs) + инерция пользователей(весьма осмотрительная в данном случае) — недоверие к этаким нововведениям. В результате имеем несколько лет времени за которые в режиме реверс-инженерии уже создадут(если будет сильно нужен) какой нибудь ReFS-4g — хотя бы для работы в режиме «только чтение».
  • –1
    Ализар, такой Ализар. NTFS уже была на вполне себе клиентской NT4 Worksation в 96 ом году.
    • –1
      То, что вас заминусовали — это просто смешно. Естественно, NT4 вполне можно считать клиентской рабочей станцией. На предприятиях они использовались вполне массово.
  • 0
    Очень любопытно, вот они квоты порежут и как мне пользователям выделять место на общем диске тогда? Да и глупость с отрезанием хардлинков это вообще бред как мне один файлик спрашивается положить в 10ть папок. Я конечно согласен что NTFS устарела но менять наточенное шило на красивую т прочную но туповатую титановую палочку (согласно этому релизу) не вижу смысла.
    • 0
      если аналогия (zfs, btrfs) верна, то квоты никуда не исчезнут, просто перейдут из ведения непосредственно ФС к разделам, которые изменять/создавать будет изрядно проще.
      • 0
        Тоже стало интересно насчет квот — нужная вещь, особенно на терминальных серверах. Но ваша фраза «просто перейдут из ведения непосредственно ФС к разделам, которые изменять/создавать будет изрядно проще» мне совершенно не понятна. ФС в принципе на разде лежит, а не наоборот. Нафига мне создавать разделы если мне нужно лимитировать пользователей по занимаемому пространству?
        • 0
          ZFS уже не «лежит» на разделе диска. ZFS использует для своего пула разные диски, разделы, файлы, а в фразе имелись в виду разделы самой ZFS, а не разделы жесткого диска.
    • +1
      Зачем вам хардлинки, если есть симлинки и junction points?
      • 0
        Хардлинки нужны и самой винде (весь сервисинг и компонентизация на них завязаны). Вот только меня поражает сколько людей (в том числе и в комментариях к исходному посту на b8) не понимают разницы между «выбросили» и «еще не реализовали, но собираемся». Точно так же как поиск файлов по object id, альтернативные файловые потоки и многое другое.

        Ну а пока не реализовали, NTFS никуда не делась (и да, по элегантности с этим старичком может соперничать разве что ZFS — в посте Чена вообще ничего про «неэлегантность» нет): если нужны возможности NTFS (те, которые еще не реализованы в ReFS) и не нужны НОВЫЕ возможности ReFS — никто не заставляет пользоваться новой ФС только потому что она новая (об этом тоже есть в оригинальном посте).
        • 0
          Можете поподробнее написать про сервисинг и компонентизацию? Речь про папку winsxs?
          • +1
            Да речь о ней — там фактически одни хардлинки и лежат. Сервисинг (Windows Update) использует еще и KTM (те самые транзакции, которые тоже «выбросили»):
            That leaves two more goals. As for platform stability, this is achieved by some of the ways that Microsoft is using TxF in its own technologies. There are three core features in Windows Vista and Windows Server «Longhorn» that now make use of Transactional NTFS: Windows Update, System Restore, and Task Scheduler. All of these use TxF to write files to the file system within the scope of a transaction in order to handle rollback/commit in case of any exceptions, such as a system reboot due to a loss of power. If you’ve ever experienced a loss of power right in the middle of Windows Update, you know this can leave your system dead and in need of a fresh installation. But now that Windows Update uses TxF, if this same situation occurs on your Windows Vista system, the computer can recover by rolling back the transaction when the system reboots. By adopting TxF internally, Microsoft has helped make its own operating system more stable.


            Собственно на все эти «выброшенные» возможности ФС завязано столько возможностей самой винды, что последняя стадия в «first as a storage system for Windows Server, then as storage for clients, and then ultimately as a boot volume» означает поддержку в ReFS всех фич NTFS. Более того, есть серьезные основания предполагать, что именно из-за их отсутствия загрузка с ReFS и не поддерживается: не думаю, что прилинковать к winload еще и ReFS это такая уж сложная задача, а после winload уже будет полноценный драйвер и никому уже не нужно знать какая там файловая система.
  • +1
    А кстати кто-нибудь в курсе чем закончилась эпопея с WinFS которую обещали сделать в Висте, потом отложили до Server 2008? Похоронили ее?
    • 0
      Мне кажется, что они как-то тихо замяли эту тему.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        WinRT не managed.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            >>но при этом опять наступая на те же грабли: основная среда — unmanaged, а «поверх» неё вертится managed среда (для C# и VB).
            Чем вам грабли? Удобность ничуть не упала, зато увеличилась скорость +!!! возможность использовать в нативном коде!!!
      • +3
        > как всегда всё опять упёрлось в совместимость и Microsoft в очередной раз делает из конфетки какашку.

        Делать обратно несовместимые вещи могут позволить себе только те, у кого рынка — с гулькин нос.
        • 0
          Рано или поздно от поддержки legacy надо отказываться, иначе не будет развития.
          Хотя в этом плане есть подвижки — гипервизор встроили в клиентские системы и постепенно выносят уровенить совместимости в ВМ.
    • 0
      WinFS не была файловой системой — это была надстройка на NTFS, части которой всплыли в вин7 в виде библиотек.
  • 0
    Когда я анализировал ReFS я увидел, что она напоминает NTFS, но многих её возможностей там нет. Действительно, ни файловых потоков, ни расширенных атрибутов. Зато сохранилась технология точек повторной обработки (reparse points), а на её основе сделаны символьные ссылки и точки монтирования каталогов и томов.

    Я думал, что хотя бы файловые потоки будут добавлены позже. Оказывается, нет. Жаль, это шаг назад.
    • 0
      Где они использовались-то? Я знаю буквально 1-2 софтины, каким-то боком использующие эту сомнительную функциональность.
      • 0
        Я знаю буквально 1-2 софтины, каким-то боком использующие эту сомнительную функциональность.

        Вирусы с антивирусами? :)
        • 0
          Ога :)
      • 0
        Альтернативные потоки используются, к примеру, Internet Explorer-ом при сохранении файлов из интернета (и Windows Explorer отказывается напрямую запускать такие файлы).
        • 0
          А, вон оно где хранилось. В макоси эти данные в расширенных атрибутах хранятся (posix-совместимых). Соответственно, могут быть скопированы, если таргет-система тоже их поддерживает (даже если не hfs), а в винде только с ntfs на ntfs максимум.
          • 0
            Ну extended attributes в ReFS тоже пока не поддерживаются. В общем фраза «no longer supported» меня несколько смущает, но я СИЛЬНО удивлюсь, если к моменту «then ultimately as a boot volume» все недостающие фичи (кроме, пожалуй, коротких имен) не будут реализованы.
  • +2
    Новая ФС! А сделать в винде полную поддержку длинных путей (>255), которые заложены в NTFS, это видимо очень сложно и не нужно.
    • 0
      В винде ЕСТЬ полная поддержка длинных путей (>260). Изменять контракт на размер буфера, который раньше был фиксированным — это не просто ломать совместимость, это напрашиваться на срывы буферов с последующим исполнением кода
      • +1
        Другое дело, что почему то сам Windows Explorer все не хочет понимать длинные имена — вот это для меня загадка.
      • 0
        Поддержка то как бы есть. Специальными программами можно копировать файлы с длинными путями, но вот Explorer уже такие папки не поддерживает. При это не придумано даже путей миграции к длинным именам. Когда переходили нам имена файлов >8.3, то механизм все поддержки старыми программами был все таки найден, хоть и кривоватый, но все же. А тут выходит Vista, который суждено было быть ОС изгоем из-за огромного числа нововведений, но поддержку длинных путей так и не сделали.
        • 0
          Хотя да, я сейчас подумал и понял, почему эксплорер не поддерживает длинные имена. У shell интерфейсов есть куча методов, которые возвращают путь, который традиционно имел максимальную длину в MAX_PATH. Из-за этих методов сам эксплорер не может иметь путь длиннее, чем MAX_PATH: к примеру, программа спрашивает текущий путь, а shell не может его вернуть.
  • 0
    Вот интересно, альтернативные потоки сделают как в ntfs? :)

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