Возобновлена работа над версионной файловой системой Tux3

После трёхлетнего затишья в разработке Дэниель Филлипс (Daniel Phillips) сообщил в списке рассылки разработчиков ядра Linux о возобновлении работы над файловой системой Tux3 и опубликовал первое сравнение производительности новой ФС, в котором показатели Tux3 оказались близки к Ext4 и даже немного опережают данную ФС. Для желающих поэкспериментировать с Tux3 предлагается использовать новый репозиторий проекта на GitHub.

Первый публичный выпуск Tux3 был представлен в 2008 году, до этого около 10 лет проект развивался под грифом внутренней разработки, нацеленной на опробование некоторых новых подходов к построению файловых систем. Файловая система Tux3 позиционируется как ФС общего назначения, которая использует версионный механизм учёта изменений и позволяет вернуться к состоянию ФС в любой момент времени в прошлом, что достигается благодаря тому, что данные при внесении изменений не переписываются, а копируются на новое место. При этом версионный контроль применяется как для ФС в целом, так и для индивидуальных файлов и директорий. Для выбранного состояния могут осуществляться версионные срезы (снапшоты), которые могут продолжать существование как самостоятельные объекты, для которых возможна запись и изменение данных.

Другими интересными особенностями Tux3 являются встроенные средства для репликации между системами отдельных файлов, директорий или целиком ФС, режим атомарного обновления данных, возможность изменение размера ФС на лету, динамическое распределение i-node (i-node хранятся в виде дерева btree и не имеют фиксированного размера или жестко заданного набора атрибутов), высокая скорость работы fsck за счёт ведения лога изменений в виде Btree-дерева, быстрый доступ к большим директориям, содержимое которых индексируется с использованием структур PHTree (в планах). Максимальные размеры файлов, разделов, числа i-node и версионных изменений практически не ограничены (2^60 и 2^48).

В отличие от файловых систем Btrfs и ZFS, Tux3 базируется на модели использования одного указателя на екстент (single-pointer-per-extent) и привязке информации о версиях к конечным узлам дерева (в классических "copy on write" системах учитывается состояние всего дерева ФС). Подобный подход позволил добиться сокращения объема мета-данных и значительного упрощения "физического" дизайна за счет переноса функциональности на "логический" уровень, что упрощает проведение таких операций как проверка целостности и восстановление после сбоя. Тем не менее, так как изменение дочерних элементов не приводит к изменению родительских в процессе монтирования приходится отталкиваться от исходного состояния элементов проигрывая все последующие изменения (в процессе работы данная особенность не сказывается, так как все изменения отражаются в прокэшированном дереве). С другой стороны подобные подход позволяет избавиться от рекурсивных операций с деревьями, свойственными copy-on-write системам.

Проведённое сравнение производительности с файловой системой Ext4 показало, что Tux3 немного опережает Ext4 (46.338/46.684, 49.101/44.011, 49.838/43.773) и при этом создаёт вдвое меньшую нагрузку на CPU. Тестирование проведено с использованием утилиты fsstress, оценивающей скорость выполнения нескольких сценариев работы с ФС, свойственных для высоконагруженных систем. В качестве одной из причин низкой нагрузки на CPU называется разделение реализации Tux3 на две раздельные подсистемы - фронтэнд и бэкенд. Фронтэнд оуществляет выполнение операций, свойственных для POSIX ФС, работает только с данными имеющимися в кэше. Бэкенд следит за синхронизацией кэша, осуществляя операции с диском в атомарном режиме. Все изменения передаются фронтэндом в виде транзакций, которые группируются в delta-наборы, с тем расчётом, что каждый набор может быть записан на носитель в виде атомарного изменения.

Несмотря на то, что ФС Tux3 уже достаточно стабильная и пригодна для экспериментов, ещё не все запланированные функции реализованы. Наиболее существенной функцией, которую планируется реализовать в первую очередь, является поддержка снапшотов. Пока не реализован в коде новый метод индексирования директорий (PHtree). Требуется доработка систем для управления свободным дисковым пространством и распределения блоков для уменьшения фрагментации. Необходимо создать эффективную утилиту для восстановления повреждённых ФС (fsck). В планах также реализация возможностей, связанных с миграцией блоков, увеличением/уменьшением размера разделов, дефрагментацией, дедупликацией и репликацией.

Источник:
http://www.opennet.ru/opennews/art.shtml?num=35741

<= Назад
Комментарии
]]> ipv6 ready Kiev LUGLinux4MeНостальгияЛичный сайт skeletora ]]>