ZFS (Zettabyte File System)  — одна из самых известных файловых систем, изначально созданная в Sun Microsystems для операционной системы Solaris, перенос которой на другие платформы вызвало всплеск диаметрально разных эмоций у разработчиков: от бурного восхищения и ликования, до прямо противоположного — раздражения и ярости.

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

• 128-битнаяфайловая система, что даёт возможность хранения практически неограниченных объёмов информации. На практике это значит, что ZFS теоретически может хранить объёмы информации, которые превышают сегодняшние технологические возможности, при условии использования текущего подхода к организации хранения данных;
• Очень большое внимание уделяется целостности и надежности хранения, как пользовательских данных, так и метаданных ФС, для этого используются продвинутые алгоритмы хэширования;
• Поддержка снапшотов (snapshot) и пулов хранения (storage pools), благодаря чему ZFS сочетает в себе возможности файловой системы и системы управления томами (новая концепция storage-пулов);
• Отсутствие необходимости в fsck благодаря транзакционной природе этой ФС;
• Традиционно считается, что ZFS — это достаточно производительная файловая система. Впрочем, это утверждение иногда ставится под сомнение. Как минимум, конкретные цифры очень сильно зависят от типа задачи, на которой производится подобное сравнительное тестирование производительности;
• Возможности для избирательного сжатия и/или шифрования отдельных файлов или файловых систем;
• Поддержка автоматического распознавания и объединения (исключения) файлов-дубликатов;
• ZFS не поддерживает квоты. Вернее сказать, её поддержка квот несколько своеобразна: понятие «выделение квоты» значит в терминологии ZFS то, что вы ограничиваете размер создаваемой файловой системы. Дизайн системы таков, что каждому пользователю ZFS следует выделять свою собственную файловую систему со всеми сопутствующими ограничениями;
• Определенные проблемы создает не техническая особенность ФС — несовместимая с GPL лицензия на код (CDDL);
• Чтобы показать инновационность ZFS не только в области технических решений, приведу, как пример, возможность управлять основными возможностями ФС через веб-интерфейс;
• И многое-многое другое, так как, повторюсь — ZFS чрезвычайно велик в своих возможностях и особенностях, и перечислить всех их здесь просто не представляется возможным.

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

Что касается резко отрицательных откликов на эту, вне всяких сомнений, уже знаменитую файловую систему, то они сводятся в основном к следующим тезисам. Один из ведущих разработчиков Linux, кстати, ответственный за поддержку её дисковой подсистемы, Андрей Мортан (Andrew Morton), разразился гневными обличениями ZFS в «чудовищном нарушении уровней реализации».

В качества ответа на эти выпады, процитирую только ведущего разработчика ZFS Джефа Бонвика (Jeff Bonwick):

«Все эти обвинения в нарушении дизайна уровней реализации файловой системы, оттого, что ZFS комбинирует в себе одновременно функциональность файловой системы, менеджера томов и программного RAID-контроллера. Я полагаю, что ответ на эту претензию будет зависеть от того, что понимать под обвинением „нарушает дизайн уровней“.  
 
В процессе разработки ZFS мы установили, что стандартный дизайн абстрагированных уровней дискового стека провоцирует удивительное количество ненужной сложности и избыточной логики. В процессе рефакторинга мы пришли к мнению, что единственное решение проблемы — это фундаментальный пересмотр границ слоев и их отношений, — что делает все сразу намного более простым».

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

Несмотря на солидных новичков описанных в авангарде, также в список ФС будущего был включен и яркий представитель «старой школы», которым в полной мере является самая прогрессивная ФС 90-ых годов — XFS.

Хотя, нужно сразу отметить, что, несмотря на то, что XFS во многом проигрывает всем трем вышерассмотренным представителям «новой школы» по отдельным решениям, при этом, в общем и целом, XFS смотрится достаточно современно, вполне удовлетворяя потребности индустрии на «сегодня», тогда как вышерассмотренные ФС проектируются уже скорее исходя из вызовов «грядущего завтра».

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

• Реализована поддержка очень больших файлов;
• Не смотря на то, что официально XFS везде позиционируется как настоящая 64-битнаяФС, стратегия дискового драйвера реализована так, что он везде, где это только возможно, избегает использования 64-битногорежима адресации, используя обычную 32-битнуюадресацию, для чего активно используются AGs (allocation group, AG);
• XFS официально — журналируемая файловая система, — но опять же, с той лишь оговоркой, что фиксируются лишь изменения метаданных, включая операции с суперблоком, AGs, inodes, каталогами и свободным пространством. При этом XFS вообще никак не журналирует пользовательские данные;
• Нужно отметить ярко выраженное следствие применения механизма отложенного размещения, о котором мы упомянули выше: его эффективность прямо пропорциональна имеющейся величине оперативной памяти (RAM), что опять-таки очень выгодно при современных тенденциях серверного оборудования;
• Реализация журнала транзакций является самым противоречивым в устройстве XFS, т.к. дизайн таков, что через него проходят все изменения метаданных файловой системы;
• Слабое место XFS — скорость обработки каталогов содержащих большое количество файлов: при таком сочетании условий, сложность реализации алгоритма листинга каталогов приводит к некоторым провалам в производительности этой ФС. В таком случае рекомендуется использование специальной утилиты xfs_fsr для оптимизации работы и устранения узких мест в скорости отклика файловой системы.

И всё-таки, несмотря на несколько скептическое отношение к XFS в этом обзоре, следует признать, что у этой ФС есть реальные шансы претендовать на большое будущее.

Как сообщает ведущий разработчик из Red Hat Валери Орорэ (Valerie Aurora), эта крупная компания всерьёз заинтересовалась XFS, пригласив к себе на работу её троих самых активных разработчиков. Так уже в 2010 году RedHat сделала более 70% всех коммитов в драйвер XFS для ядра Linux, а в 2011-2012 годах намерена продолжить серьёзное развитие XFS, для достижения паритета её возможностей с ведущими ФС «новой школы».

Этот же разработчик отмечает, что если дополнительно учесть очень тщательное комментирование XFS (примерно 40% всех строк в исходниках драйвера — это комментарии к коду), то раздувание и усложнение кодовой базы btrfs будет даже ещё большим (против 17% комментариев соответственно).

Hammer  — это 64-битная кластерная файловая система построенная на B-деревьях, созданная специально для своего проекта DragonFly BSD известным гуру из FreeBSD Project, — Мэттью Диллоном (Matthew Dillon).

Давайте перечислим основные возможности HAMMER, которые доступны уже на данный момент (или реализация которых близка к завершению):

• HAMMER — это файловая система доступная немедленно даже после падения и перезагрузки системы, здесь нет fsck ;
• Размер ФС HAMMER может достигать размера до 1 экзабайта (1 миллиард гигабайтов), и может при этом вмещать в себя до 256 томов, каждый из которых может достигать размера до 4 петабайтов (4096 терабайтов).
• Возможность отката любой дисковой операции и возврата состояния ФС в определенную точку;
• Метод крупнозернистой истории реализуется через мгновенные снимки ФС (снапшоты). По умолчанию, системный крон генерирует один снапшот в день, который хранится в течении 60 дней. Количество и частота снапшотов неограниченна. Все хранимые снапшоты индексируются также посредством B-дерева таким образом, чтобы сделать их хранение на носителях максимально эффективным. Каждый отдельный снапшот полностью отражает состояние файловой системы в заданный промежуток времени. Параллельный метод — мелкозернистой истории, — фиксирует все системные операции в пределах около 20-60 секунд, которые также доступны для отката или повтора (undo/redo options), а также их анализа в случае любого сбоя (мелкозернистая история используется, чтобы избежать избыточных и ресурсоемких операций характерных для снапшотов, при этом, не теряя непрерывного контроля за системой);
• Возможность инкрементального зеркалирования без использования очередей операций, поддержка режима «один master и много slave»;
• Заканчивается тестирование работы в multi-master режиме с распределением данных на несколько хостов сети (резервирование за счет дублирования данных на разные машины). Также реализована поддержка асинхронных транзакций;
• Возможности для создания псевдо-файловой системы (PFS) внутри файловой системы HAMMER. Можно создать до 65535 таких файловых систем. Каждая PFS использует независимое пространство нумерации inode‘ов, что позволяет использовать её в качестве источника или цели репликации;
• Реализована система контроля максимально эффективного распределения пропускной способности канала при выполнении множественного бэкапа ФС (или её PFSs) на её slave-PFSs физически находящиеся на удаленных хостах;
• Поддержка автоматического объединения дубликатов данных на всех PFS (дедупликация);
• Из недостатков — для очистки и реблокинга ФС (pruning/reblocking ops) требуется регулярный запуск специальной сервисной задачи (она выполняется быстро, как правило, в пределах нескольких минут).

Практические выводы