Hammer

http://www.dragonflybsd.org/hammer/

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

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

• Hammer — это файловая систе­ма, доступная немедленно даже после падения и перезагрузки системы, здесь нет fsck.

• * Размер ФС Hammer может до­стигать размера до 1 экзабайта (1 миллиард гигабайт), при этом вмещать в себя до 256 томов, каждый из которых может дости­гать размера до 4 петабайт (4096 терабайт).

• Возможность отката любой дисковой операции и возврата состояния ФС в определен­ную точку.

• Метод крупнозернистой истории реализуется через мгновен­ные снимки ФС (снапшоты). По умолчанию системный крон ге­нерирует один снапшот в день, который хранится в течение 60 дней. Количество и частота снап­шотов не ограничена. Все храни­мые снапшоты индексируются также посредством В-дерева таким образом, чтобы сделать их хранение на носителях мак­симальноэффективным. Каждый отдельный снапшот полностью отражает состояние файловой системы в заданный промежуток времени. Параллельный метод мелкозернистой истории фик­сирует все системные операции в пределах около 20-60 секунд, которые также доступны для отката или повтора (undo/redo options), а также их анализа в случае любого сбоя (мелкозер­нистая история используется,

(Чтобы избежать избыточных и ресурсоемких операций, харак­

терных для снапшотов, при этом не теряя непрерывного контроля за системой).

• Возможности для создания псев- дофайловой системы (PFS) вну­три файловой системы Hammer. Можно создать до 65.535 таких файловых систем. Каждая PFS задействует независимое про­странство нумерации inode’OB, что позволяет использовать ее в качестве источника или цели репликации. Реализована си­стема контроля максимально эффективного распределения пропускной способности канала при выполнении множественного бэкапа ФС (или ее PFSs) на ее slave-PFSs, физически находя­щиеся на удаленных хостах. Нелишним будет еще раз под­черкнуть, что Hammer в стабильной версии доступен на данный момент лишь на своей родной DragonFly BSD (имеется экспериментальный FUSE-модуль для Linux, который позволяет работать с этой ФС в режиме read-only).

Ссылки по теме Hammer:

http://en.wikipedia.org/wiki/HAMMER

http://www.dragonf lybsd .org/hammer/hammer.pdf

http://dlorch.github.com/hammer-linux/

XFS

www.xfs.org

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

файловая система, созданная ком­панией Silicon Graphics, полностью основанная на уже проверенной временем технологии В-деревьев. Следуя уже привычной схеме, при­ведем ее типичные черты, также остановившись и на недостатках, которые отчетливо проступают по мере ее использования в современ­ных условиях.

• Реализована поддержка очень больших файлов.

• Несмотря на то что официально XFS везде позиционируется как настоящая 64-битная ФС, стра­тегия дискового драйвера реали­зована так, что он везде, где это только возможно, избегает ис­пользования 64-битного режима адресации, используя 32-битную адресацию, для чего активно используются AGs (allocation group, AG).

• XFS официально — журналируе­мая файловая система, но опять же с той лишь оговоркой, что фиксируются лишь изменения метаданных, включая операции с суперблоком, AGs, inodes, ка­талогами и свободным простран­ством. При этом XFS вообще никак не журналирует пользова­тельские данные.

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

Интересно также, что, по словам Эрика Сандина (Eric Sandeen), еще одного из разработчиков XFS в RedHat, XFS, которая традиционно считается очень сложной реализацией ФС, в процессе ее развития постепенно упрощается — что хорошо заметно

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

Ссылки по теме XFS:

http://oss.sgi.com/projects/xfs/

http://xfs.org/index.php/XFS_FAQ

http://oss.sgi.com/projects/xfs/design_docs/

http://filesystems.nm.ru/my/xfs_arch.pdf

http://xfs.org/index.php/XFS_Status_Updates

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

Ну что ж, ознакомившись с наи­более перспективными файловыми системами ближайшего будущего по версии экспертов Google, по­пробуем определиться и сделать свой выбор, чтобы как следует под­готовиться, как выразился вышеупомянутый разработчик из Google, к приходу «Эпохи Больших Данных».

И нашу практическую часть об­зора предлагаю начать с XFS. Эта файловая система очень хорошо масштабируется, она уже сейчас способна оперировать огромными объемами данных. Большая скорость ввода-вывода — конек этой файловой системы. Дополнительным условием эффективности XFS является наличие качественного питания (внезапные от­ключения достаточно неприятны для нее) и больших объемов оперативной памяти на сервере, что позволяет раскрыть весь потенциал механизма отложенного размещения и прочих «ленивых» техник, обильно реализо­ванных в XFS. Сильная многопользо­вательская нагрузка на хранилище позволяет продемонстрировать XFS свой инновационный механизм параллельной записи и низкую ресур- соемкость.

При этом важно понимать, что идеала не существует, и узким местом именно этой ФС являются операции над большим количеством мелких файлов или удаление развесистых деревьев каталогов — в этом случае вы вряд ли увидите ту производи­тельность, на которую рассчитывали. Если не считать большой проблемой невозможность уменьшить размер уже созданной ФС — вот, пожалуй, и все узкие места этой надежной и уже проверенной временем файловой си­стемы. Что касается конкретных реа­лизаций, то XFS прекрасно чувствует себя как на Linux, так и на FreeBSD, поэтому выбрать платформу для хра­нилища здесь есть из чего.

Что же касается ZFS, то первое что приходит на ум, это параноидальное недоверие этой ФС к железу, когда контроль за целостностью данных носит многоуровневый и чрезвы­чайно изощренный характер. Здесь невольно вспоминается, что на заре SATA, когда первые диски с этим интерфейсом выпускались с боль­шим количеством брака, порождая проклятия особенно со стороны об­ладателей ext2, разработчиков ZFS на многих конференциях можно было увидеть в майках с мессианской над­писью «ZFS любит SATA», они как бы подчеркивали, что эта ФС способна позаботиться о вверенных ей данных, даже если само «железо» не всегда способствует этому. Поэтому, если у вас в серверной обилие дешевого железа, или ваши серверы хранят просто бесценные данные (или, для наибольшей изощренности, и то и другое вместе), ZFS будет очень удач­ным выбором.

С другой стороны, степень мас­штабируемости системы под ZFS просто безгранична. Если учесть скорость ее работы, как правило, выше среднего и огромный выбор и гибкость настроек (добавьте сюда родной менеджер томов и про­граммный RAID-контроллер) — это, пожалуй, идеальный выбор для соз­дания больших хранилищ данных. И если последнее утверждение можно смело отнести к Solaris/FreeBSD, то в отношении Linux нужно сделать отдельную важную оговорку.

ZFS не была включена в ядро Linux из-за патентных ограничений, и чтобы обойти это, был собран FUSE-модуль для поддержки этой ФС в Linux на пользовательском уровне. Конечно, потери скорости и стабильности работы в таком варианте ФС огром­ны. Но, к счастью, существует как минимум два сторонних решения, где поддержка ZFS реализована все- таки на уровне ядра в качестве само­стоятельного модуля. Это прежде всего Native ZFS во главе с Брайаном Белендорфом (проект финансируется Министерством энергетики США). Во-вторых, альтернативный, но такой же открытый и бесплатный вариант от индийской компании KQ Infotech. Лично я рекомендую остановиться на последнем варианте, так как это более качественная и полная реализация ZFS для Linux (дополнительно обе­спечена поддержка ZFS POSIX Layer). Но в обоих случаях, несмотря на все озвученные плюсы, ZFS все-таки не самый сильный выбор для Linux, так как вы останетесь с этим выбором наедине, лишенные поддержки со стороны официальных разработчиков ядра, тем более если учесть скорое пришествие Btrfs…

Кстати, о Btrfs. Имеет смысл рас­сматривать эту ФС пока приме­нительно только к ОС Linux (то же самое можно сказать и о Hammer к DragonFlyBSD), и можно определен­но сказать, что через годик-другой это будет наиболее универсальный и взвешенный выбор для этой ОС из всех возможных. А пока… эта файло­вая система отлаживается, расширя­ется, растет и активно проходит фазу становления, необходимую для ее окончательного взросления. По сло­вам ее ведущего разработчика, пере­ход на эту ФС в качестве основной для Linux запланирован на 2013 год.

Игорь САВЧУК