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



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

    В традиционных системах хранения данных действия осуществляются как над небольшими блоками информации определенных размеров, так и над метаданными. На сегодняшний день развиваются системы хранения объектов, где вместо блоков с данными оперируют объектами, имеющими различные параметры. Системы хранения объектов базируются на стандарте T-10 Object Storage Devices (OSD).

    Фундаментальное различие между блочными и объектными системами хранения заключается в том, что в первом случае вы создаете объекты из наборов блоков, содержащих данные и метаданные, а во втором – оперируете с объектами и соответствующими им метаданными напрямую.



    Рисунок 1 – Блочная и объектная системы хранения

    Одним из примеров файловых систем, построенных над системой хранения объектов, может служить exofs (Extended Object File System).

    Схему exofs можно изобразить следующим образом:



    Рисунок 2 – Схема exofs

    Виртуальный переключатель файловых систем VFS (Virtual File System Switch) дает доступ к exofs, а exofs уже взаимодействует с системой хранения объектов через локальный инициатор OSD.

    Хотя хранение объектов является интересной идеей, Рави Тандон (Ravi Tandon), выпускник факультета компьютерных наук, считает, что будущее за log-структурированными файловыми системами. «Это мое мнение, так как в дальнейшем развитии систем хранения большую роль сыграют flash и SSD-технологии», – говорит Рави. Log-структурированные файловые системы идеально подходят для твердотельных накопителей, поскольку в этом случае операции записи распределяются равномерно по всему устройству, что ведет к снижению количества циклов стирания данных – это позволяет значительно продлить срок жизни SSD.

    Идея log-структурированной файловой системы была предложена еще в 1988 году Джоном Остераутом (John Ousterhout) и Фредом Дуглисом (Fred Douglis), а реализована в 1992 году в операционной системе Sprite. Суть здесь в следующем: файловая система представляется в виде циклического журнала, куда записываются новые данные и метаданные, причем свободное место всегда берется с конца. Это означает, что в журнале может оказаться множество копий одного файла, но активной будет всегда считаться самая актуальная из них. Эта интересная особенность позволяет получить несколько преимуществ.



    Рисунок 3 – Log-структурированная файловая система

    Этот подход к хранению данных ведет к снижению накладных расходов при записи – запись осуществляется последовательно, данные быстрее оказываются на диске, потому файловая система работает быстрее. Еще Рави Тандон пишет, что log-структурированные системы поддерживают такие функции, как контроль версий и восстановление данных, фактически позволяя вам «путешествовать во времени».

    Примером log-структурированной файловой системы может служить NILFS2. NILFS2 действительно умеет создавать моментальные снимки состояния файловой системы. Это очень удобно, если вам потребовалось восстановить ранее удаленные или утерянные файлы. Однако за все приходится платить, log-структурированная файловая система также не лишена недостатков – здесь приходится использовать сборщик мусора, чтобы удалить старые данные и метаданные. В эти моменты может наблюдаться значительное снижение производительности.

    Два рассмотренных типа файловых систем конечно хороши (хоть и не лишены недостатков), однако есть и другие стоящие идеи. В частности, Джефф Дарси (Jeff Darcy), программист и блогер, считает, что в течение нескольких лет произойдет разделение на локальные и распределенные файловые системы, где вторые будут строиться на основании первых. Что касается первого случая, то последнее время все большую популярность приобретают файловые системы ZFS и Btrfs.

    ZFS (Zettabyte File System) – это 128-битная файловая система, которая поддерживает файлы до смешного огромных размеров (16 эксабайт) и способна работать с дисковыми объемами до 256 зеттабайт. Лидер проекта ZFS Джефф Бонвик (Jeff Bonwick) сказал, что «заполнение 128-битных файловых систем превысит квантовые возможности хранения данных на Земле». «Вы не сможете заполнить и хранить 128-битный объем, не вскипятив при этом океаны», – отметил Бонвик.

    Пример того, насколько велики эти числа: если создавать тысячу файлов ежесекундно, то для достижения предела количества файлов в ZFS потребуется около 9000 лет. Вообще файловая система ZFS спроектирована таким образом, чтобы нельзя было столкнуться с какими-либо ограничениями в обозримом будущем.



    Рисунок 4 – Традиционные файловые системы и ZFS

    ZFS строится поверх виртуальных пулов с данными (zpool). Получается так, что все подключенные диски являются частью одного гигантского раздела. Более того, диски могут связываться друг с другом в виртуальные RAID-массивы, которые обладают способностью к «самоисцелению». Еще эта файловая система позволяет делать снапшоты, чтобы восстановить данные в случае повреждения. Подробнее о ZFS можно узнать здесь.

    Файловая система Btrfs является прямым конкурентом ZFS и обладает практически теми же функциями. В качестве пары примеров сравнительного анализа можно посмотреть вот эти две статьи: 1 и 2.

    www.diva-portal.org/smash/get/diva2:822493/FULLTEXT01.pdf

    Что же касается распределенных файловых систем, то, по словам Джеффа Дарси, который занимается разработкой GlusterFS, за ними будущее. Однако в этом случае приходится уделять много внимания надежности. Вообще распределенная файловая система – это скопление независимых компьютеров, которые для пользователя выглядят как единая целостная система.

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



    Рисунок 5 – Выгрузка для DFS

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

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

    Кстати, совсем недавно мы рассказывали о том, как проверить надежность дата-центра (тут и тут). Помимо этого мы привели примеры наших кейсов и подготовили календарь мероприятий на 2016 год по теме ИТ-инфраструктуры, ИБ и телекома.
    ИТ-ГРАД
    220,59
    vmware iaas provider
    Поделиться публикацией

    Комментарии 19

      +3
      «Обе эти файловые системы находятся в стадии тестирования и не являются стабильными, однако выглядят многообещающе.»

      ZFS не стабильная? ZFS в стадии тестирования?
      Ну тогда ext4 вообще экспериментальная
        +2
        Хотя бы вот. Возможно с последними патчами большинство проблем было исправлено, но не известно, что будет дальше. «If you want people to think something's production ready, stop putting „0.xxxx“ in your version numbers» (и еще)
          +4
          Так пишите корректно «Порт ZFS на Linux находиться в стадии тестирования».
          На Solaris и FreeBSD это production файловая система.
            +2
            Так пишите корректно «Порт ZFS на Linux находиться в стадии тестирования».
            А ещё корректнее «Порт ZFS на Linux находится в стадии тестирования»…
        0
        Есть один технический момент. 9000 лет по 1000 файлов в секунду при размере адреса 2^128…

        Log[10, 2^128]=38.53
        Log[10, 9000*365*24*3600*1000 ]=14.45

        Ошибочка на 24 порядка, если я ничего не путаю.

        Получается, что необходимо будет на миллиарде машин по миллиарду файлов в секунду записывать, и только через триллион лет закончится адресное пространство.
          +3
          Wiki: 128-битная файловая система, 2^48 – количество файлов в любой индивидуальной файловой системе (2×10^14)
          +3
          Небольшой оффтопик касательно файловых систем.

          У меня последнее время еще теплится надежда получить дедубликацию данных на локальном компьютере.

          Базовый сценарий использования: есть утилита, например git-lfs. Она держит каждый файл на диске в нескольких экземплярах (в кэше скачивания и рабочей копии). Хочется, чтобы физически файл записывался на диск один раз (экономия места и времени на запись), т.е. использовать copy-on-write файлов.

          Под Linux с Btrfs копирование фалов через copy-on-write уже умеет утилита cp из coreutils (с флагом --reflink=auto). И для git-lfs патч выглядит не очень страшно: github.com/github/git-lfs/pull/952

          Вопрос: куда копать в стане Windows для получения схожего функционала?
            0
            Я агитировал разработчиков ReactOS использовать ZFS. Но они меня не послушали. Может надо было активнее их трясти :-)
              +1
              Я боюсь, что наличие данной фичи в ReactOS меня бы не спасло :)
                0
                Что значит «не послушали?». Мы принимаем патчи. /улыбаюсь.
                  0
                  «Непослушали» — значит сказали, что FUSE — это неправильно, и поддержка юниксовых FS вам не нужна.
                  Я думал сам попробовать прикрутить, но не смог из-под Linux собрать ReactOS. А дальше уже времени не было занятья, к тому же я решил на C/C++ больше ни чего не делать.
                    +1
                    смог из-под Linux собрать ReactOS
                    .
                    Очень странно, у нас наверное больше половины разработчиков под линуксом кодит.

                    FUSE — это неправильно, и поддержка юниксовых FS вам не нужна.
                    . Видимо, произошло недопонимание.
                    Мы недавно добавили поддержку EXT1\2\3
                +1
                Для серверной версии есть дедупликация из коробки, для клиентской некоторые люди просто файлы с сервера копируют и запускают на свой страх и риск
                  0
                  Я видел это решение и до сих пор не могу развидеть:
                  • дедупликация прикручена сбоку;
                  • с дедуплицируемого раздела нельзя загружаться;
                  • с дедуплицируемого раздела нельзя читать данные чем-либо кроме Windows с установленной дедупликацией;
                  • API для создания клона файла отсутствует (или я плохо искал?);
                  • изначально файл создается как «обычный файл», а потом при помощи внешней магии превращается в «дедуплицируемый» файл. И на уровне NTFS это совершенно разные вещи.
                    0
                    После того, как я потерял и восстанавливал (восстановил) дедуплицированный раздел со Storage Spaces, я тоже не в особом восторге. Но есть и бонус
                    > дедупликация прикручена сбоку
                    Зато запись всегда на максимальной скорости и не требует ресурсов CPU

                      0
                      > Зато запись всегда на максимальной скорости и не требует ресурсов CPU

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

                zfs diff [-FHt] snapshot snapshot|filesystem
                  0
                  Бесполезно объяснять — он где-то слышал, что у кошки 4 лапы и у коровы 4 — значит они одинаковые.
                  0
                  Файловая система — инструмент, выбираемый под задачу (с сопутствующими ограничениями и «хотелками»). Не всегда более технически продвинутое решение оптимально.
                  Подскажите, где можно найти сравнение файловых систем в характерных для них сценариях использования, а не только по набору возможностей. Особенности сценария определили и закрепили, например, fat32 на носителях для фото и др. техники.

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

                  Самое читаемое