Крис Мэйсон (Chris Mason), один из главных разработчиков Btrfs (B-tree FS), давно работает в Facebook и это, несомненно, идёт на пользу btrfs, так как задачи у такого высоконагруженного проекта соответствующие.
Btrfs - это достойный ответ замечательной ZFS, которая с linux системами имеет юридические тёрки из-за несовместимых лицензий. ZFS является проектом с открытым исходным кодом и лицензируется под CDDL (Common Development and Distribution License), из-за которой возникли проблемы с быстрым появлением ZFS в Linux. В Linux перенос ZFS на уровень ядра считался юридически невозможным из-за несовместимости лицензий CDDL, под юрисдикцией которой находится ZFS, и GNU GPL, под юрисдикцией которой находится Linux.
В мае 2010 года Брайан Белендорф (Brian Behlendorf) представил проект, в рамках которого ведется работа по реализации родной поддержки файловой системы ZFS для Linux. Для обхода лицензионного ограничения Белендорф воспользовался простым и очевидным методом — он решил распространять свой продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра.
Вся эта юридическая катавасия с ZFS одно время заставила пристально глянуть на проект btrfs. Тут стоит вам напомнить, что ZFS и btrfs - это не файловый системы, точнее НЕ ТОЛЬКО. Обе системы являются менеджерами логических дисков (томов) И файловыми системами. Чистая файловая система - это серия ext2/3/4. ZFS и btrfs могут своими силами сделать программные RAID.
Работая во Facebook, главные разработчики btrfs вносят патчи, улучшающие её работу с реально большими данными и объёмами. В ядре linux 4.1 будет улучшение free space cache writeout, которое исправляет замирание процесса записи в системах с объёмом ~20 терабайт. Исправлено замедление удаления огромных файлов размером больше 3 терабайт.
Многие разработчики связаны cоглашением о неразглашении (Non-disclosure agreement - NDA), поэтому крохи информации, периодически просочившиеся в прессу, на вес золота. Btrfs славится своей отличной работой с маленькими файлами и одновременно с файлами огромного размера, то есть параметр IOPS (input/output operations per second) традиционно высок. Первая попытка использовать btrfs во Facebook была предпринята для серверов web tier. Это здорово!
Но одно время btrfs вменяли плохую работу с СУБД и поэтому, дескать, в том же Facebook используется XFS там где есть базы данных. Хотя Крис Мэйсон проводит работу в этом направлении и от него слышали о btrfs + key-value хранилище RockDB (запомните это слово), но деталей нет. В это же время, проект CoreOS отказался от btrfs в пользу ext4 + OverlayFS. Обсуждение отказа от использования Btrfs в CoreOS было вызвано рядом проблем, которые возникли в результате её применения для нужд проекта: "Мы выбрали btrfs, поскольку она была очевидным двигателем Docker на тот момент. Однако пользователи CoreOS регулярно сообщали о багах в btrfs, среди которых упоминались ошибки о закончившемся дисковом пространстве, проблемы с повторной балансировкой метаданных, требующей ручного вмешательства, и плохая производительность в целом по сравнению с другими файловыми системами".
И ещё одна заметка. Есть такой замечательный проект Ceph, который предоставляет вам возможность создать программное хранилище из множества серверов и дисков с автоматической репликацией и восстановлением. На данный момент с каждым диском связан свой демон OSD, который через интерфейс ObjectStore с единственной реализацией в виде FileStore сохраняет данные в виде файлов. НО ведутся работы по добавлению реализации Key/Value Stores, которая поможет избежать недочётов FileStore. Среди Key/Value Stores мелькает и наш RockDB, НО btrfs до сих пор не рекомендуется разработчиками Ceph, а рекомендуются лишь ext4 и XFS! Почему? Загадка!
От себя хочется пожелать проекту btrfs удачи и просьба - ускорьтесь в разработке чуток!
Дата последней правки: 2015-06-17 11:14:44