понедельник, апреля 06, 2009

Файловая система Btrfs

Это конспект моего доклада на семинаре, организованном нашей LUG совместно с университетом. Опять же, времени было пшик, так что доклад весьма обзорный.


Введение

Речь пойдёт о файловой системе нового поколения. Традиционно ФС играла значительную роль в организации Unix-систем. И во многом именно свойствами ФС определялись свойства той или иной реализации Unix.

Файловая система должна хранить файлы и обеспечивать доступ к ним. При этом к ней предъявляется большое количество требований, зачастую взаимоисключающих: поддержка файлов любого размера, высокая производительность операций ввода/вывода, масштабируемость и т.д. Давно стало ясно, что ни одна файловая система не может быть одинаково эффективна во всех случаях. Поэтому все современные реализации Unix поддерживают работу с несколькими типами ФС одновременно. Есть такое выражение: "Linux - это Unix сегодня", и ядро Linux поддерживает свыше 50 (!) типов ФС.

ФС нового поколения

В 2005-м году компания Sun Microsystems представила файловую систему ZFS, которая стала прорывом в области файловых систем. Из-за лицензионной политики Sun ZFS не может быть включена в ядро Linux. Однако в 2007-м году началась разработка файловой системы нового поколения для Linux - Btrfs. Разработку оплачивает компания Oracle, однако код выпускается под лицензией GNU GPL и входит в ядро Linux начиная с релиза 2.6.29, вышедшего на этой неделе.

Приведу фрагмент интервью Chris Mason - основного разработчика Btrfs:

  • Опишите Btrfs своими словами.

  • Btrfs - это новая файловая система, выпускаемая под GPL, которая разрабатывается с учётом масштабируемости на очень большие объёмы носителей. Масштабируемость означает не только возможность адресовать блоки носителя, но также возможность работать с повреждениями данных и метаданных. Это означает наличие инструментов для проверки и восстановления файловой системы без отмонтирования, и интегрированную проверку контрольных сумм, чтобы определять ошибки.

  • Является ли Btrfs наследницей какой-нибудь другой ФС?

  • Да, всех их :) Здесь много идей из ReiserFS, отложенное размещение и другие идеи из XFS. ZFS популяризовала идею, что подсчёт контрольных сумм данных может быть быстрым, и что управление логическими томами может быть лучше. Идеи по реализации управления томами пришли из AdvFS.

Основные возможности Btrfs

Итак, основные возможности, которые будут в Btrfs:

  • Поддержка доступных на запись снапшотов (аналог клонов ZFS). Кроме того, здесь можно создавать снапшоты снапшотов.

  • Поддержка субтомов --- множественных именованных корней в одной файловой системе с общим пулом хранения.

  • Поддержка сложных многодисковых конфигураций --- RAID уровней 0, 1, 5, 6 и 10, а также реализация различных политик избыточности на уровне объектов ФС --- то есть возможно назначить, к примеру, зеркалирование для какого-либо каталога или файла.

  • Copy-on-write (CoW) журналирование.

  • Контроль целостности блоков данных и метаданных с помощью контрольных сумм.

  • Зеркалирование метаданных даже в однодисковой конфигурации.

  • Полностью распределенное блокирование.

  • Поддержка ACL.

  • Защита от потери данных.

  • Выбор хэш-алгоритма.

  • Поддержка NFS.

  • Флаги совместимости, необходимые для изменения дискового формата в новых версиях btrfs с сохранением совместимости со старыми.

  • Резервные копии суперблока, по крайней мере --- по одной на устройство.

  • Скоростные приоритеты для дисков.

  • Гибридные пулы. btrfs старается перемещать наиболее используемые данные на самое быстрое устройство, вытесняя с него "залежавшиеся" блоки. Эта политика хорошо согласуется с появившейся недавно моделью использования SSD (Solid State Drive).

  • Балансировка данных между устройствами в btrfs возможна сразу после добавления диска к пулу, отдельной командой --- а не только постепенно, в процессе использования (как это реализовано в ZFS).

  • Диски для горячей замены, поддержка которых появилась и в ZFS.

  • Он-лайн конфигурирование RAID будет реализовано на уровне объектов файловой системы --- субтомов, снапшотов, файлов. Возможно будет также устанавливать некоторые параметры ввода-вывода для каталогов --- с наследованием этих свойств всеми дочерними объектами.

  • Конвертер из ext2/3/4.

Большинство из этих возможностей уже реализованы и работают.

Принципы устройства

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

  • B-деревья везде, где они имеют смысл

  • Copy-on-write везде, где это имеет смысл

  • Политика блокировок - высокая гранулярность блокировок.

B-деревья и дали название файловой системе (B-tree FS). B-деревья - это сильноветвящиеся деревья (B-деревья почему-то часто путают с двоичными деревьями, видимо, из-за буквы B, но она означает Block; у каждого узла в B-дереве обычно несколько тысяч потомков), каждый узел которых, в свою очередь, содержит большое количество записей (они обычно организуются в двоичное сбалансированное дерево; в частности, в Btrfs используются красно-чёрные деревья). Читаются и пишутся узлы B-дерева целиком, что даёт значительный выигрыш в производительности.

Copy-on-write (CoW) - это алгоритм, предназначенный для ситуаций, когда нужно создавать много похожих объектов. Рассмотрим, например, создание снапшота ФС. Снапшот - это мгновенная копия всех данных части ФС в данный момент времени. Реализация "в лоб" предусматривает создание копий всех файлов, что займёт много времени и много дискового пространства. При использовании CoW создаётся только один новый объект - копия корневого каталога, а на всех файлах, на которые ссылается корневой, ставится специальная метка. Когда приложение пытается писать в "помеченный" каталог, ФС прозрачно для приложения делает его копию (помечая при этом все файлы в этом каталоге), и приложение пишет уже в созданную копию. Таким образом, создаются копии только изменившихся данных, и только тогда, когда данные действительно изменяются. Это позволяет сделать операцию создания снапшотов почти мгновенной даже для очень больших разделов. Это немаловажно, т.к. одно из основных требований к операции создания снапшота - атомарность, т.е. эта операция не должна прерываться (и конфликтовать) никакими другими операциями. В Btrfs CoW используется не только при создании снапшотов, но и при ведении журнала и многих внутренних операциях.

Блокировки - это сущность, позволяющая избежать конфликтов при одновременном доступе к данным из разных потоков. Поток, который хочет внести изменение в некоторую структуру данных, сначала проверяет, не заблокирована ли она другим потоком; если заблокирована - ждёт, пока блокировка не будет освобождена, иначе сам захватывает блокировку, и освобождает её по окончании записи. Когда речь идёт о доступе к сложным структурам данных, возникает вопрос о политике блокировок. Нужно ли блокировать всю структуру целиком, или каждый элемент в отдельности, или элементы какими-то группами? Чем крупнее единица блокировки, тем меньше блокировок, и меньше накладных расходов. Чем мельче - тем более эффективно расходуется процессорное время, т.к. потокам приходится ждать гораздо меньше. Btrfs стремится блокировать как можно меньшие элементы структур (но не слишком мелкие).

Ещё один пункт, связанный с блокировками, специфичен для ядра. В ядре есть два вида блокировок: spin-lock и мьютексы. При использовании spin-lock ожидающий поток "крутится" в бесконечном цикле. При использовании мьютексов - поток переходит в заблокированное состояние TASK_INTERRUPTIBLE, и "пробуждается" планировщиком автоматически при освобождении блокировки. Понятно, что мьютексы более эффективны, т.к. не тратят процессорное время на пустые циклы. Но мьютексы не могут быть использованы в контексте обработчика прерывания, т.к. в этом состоянии планировщик не работает. Значительная часть функций любой ФС может быть вызвана как из обработчика прерывания, так и в контексте задачи. Поэтому во многих функциях приходится использовать менее эффективные спин-блокировки.

Btrfs использует новый тип блокировок, которые могут работать в обоих режимах (и их можно переключать между режимами). Таким образом, один и тот же код будет использовать мьютексы в контексте задачи и спин-блокировки в режиме прерывания.

Ещё одна особенность Btrfs: все структуры ФС могут находиться в произвольных местах раздела, они связаны между собой указателями. Этой особенностью обладают и некоторые другие ФС, но разработчики Btrfs нашли ей новое применение: конвертация разделов из других ФС (сейчас реализована конвертация из ext2/3, конвертер из ext4 в разработке, теоретически можно создать конвертеры из других ФС). При конвертации структуры Btrfs создаются в местах раздела, помеченных в исходной ФС как свободные. В Btrfs создаётся специальный файл, в который входят блоки, занятые структурами исходной ФС. Таким образом, эти блоки оказываются помеченными как занятые. Кроме того, этот файл представляет собой образ исходной ФС, который можно примонтировать (mount -o loop). Это позволяет выполнить откат к предыдущей ФС. Чтобы освободить место на диске, достаточно просто удалить файл с образом исходной ФС (возможность отката, соответственно, пропадёт).

Одна из особенностей современных ФС не так давно вызвала небольшой скандал. Дело в том, что в ядрах unix (и linux) код ФС не занимается непосредственно записью данных на диск. Данные записываются в страницы памяти, и эти страницы помечаются как "грязные", и затем их сбрасывает на диск отдельный поток ядра (pdflush). Так вот, при использовании современных ФС (в той новости речь шла про ext4, но теми же свойствами обладают и XFS, и Btrfs, и многие другие) интервал между записью данных в страничный кэш и их записью на диск может достигать 150 секунд (больше двух минут). Unix традиционно пишется для хорошего оборудования. В частности, предполагается, что в любой системе, от которой нужна надёжность, применяются UPS. Поэтому большая задержка записи является не недостатком, а преимуществом: это даёт возможность разместить данные более удачно, и избежать фрагментации. А при использовании на менее надёжном оборудовании нужно просто перенастроить ядро средствами sysctl, чтобы заставить pdflush срабатывать чаще.

Btrfs vs Ext4

Другая недавно вышедшая ФС для Linux - это Ext4. Она учитывает многие наработки современных ФС (экстенты, delayed allocation итп), но при этом основана на коде Ext3. Это более продвинутая ФС, чем та же ext3, по тестам она во многих случаях даёт бОльшую производительность и может быть рекомендована для использования на многих машинах уже сейчас. Но при этом её не назовёшь ФС нового поколения: архитектура осталась от ext3.

Btrfs сейчас в стадии experimental, разработчики предупреждают, что сейчас её имеет смысл использовать только для тестирования и экспериментов. Даже дисковый формат до сих пор окончательно не устаканился. Но при этом это безусловно ФС нового поколения, по архитектуре она напоминает разве что ZFS, но не старые ФС linux-ядра.

Btrfs vs ZFS

Больше всего Btrfs похожа на ZFS от компании Sun. Btrfs не поддерживает диски такого астрономического объёма, как zfs, но вряд ли это в ближайшее время будет иметь практическое значение. Зато Btrfs имеет некоторые возможности, отсутствующие в zfs: снапшоты снапшотов и скоростные приоритеты дисков, оптимизацию для ssd-накопителей. Но ZFS уже вовсю используется на production-серверах, а использование btrfs станет массовым, видимо, года через два (если предполагать, что распространение btrfs будет развиваться также, как zfs).

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

Текущее состояние разработки

Основные возможности Btrfs уже реализованы. Дисковый формат близок к стабилизации, если он и будет меняться, то не сильно. Только что завершена реализация обработки ситуации нехватки места на диске (проблема в том, что фактическая запись на диск может происходить уже после закрытия файла программой, и было не совсем очевидно, как передать ошибку записи программе). Вовсю идёт поиск и исправление других ошибок. В разработке специальный ioctl-API для поддержки транзакционного I/O (несколько операций, объединённых в транзакцию, могут быть выполнены все или не выполнены совсем; кроме всего прочего, это позволяет минимизировать количество проверок между операциями в одной транзакции). Ближайшая задача - реализация удаления снапшотов, первый вариант кода уже появился в рассылке.

14 комментариев:

  1. осилил, половину не понял, но понравилось
    спасибо

    ОтветитьУдалить
  2. Анонимный4/08/2009 3:37 ДП

    > B-деревья почему-то часто путают с
    > двоичными деревьями, видимо, из-за
    > буквы B, но она означает Block;

    B означает Balanced.

    ОтветитьУдалить
  3. Анонимный4/08/2009 5:28 ДП

    > • Поддержка ACL.

    А Extended Attributes?

    > • Защита от потери данных.

    За счет чего? Про CoW уже было.

    > • Резервные копии суперблока, по крайней мере --- по одной на устройство.

    В ZFS копий всего 4: две в начале диска, две в конце, размером по 256Kb. И то на мой взгля мало.
    Помню как из-за глюка в ata-драйвере на FreeBSD ZFS испортила первые две копии. Спасло только наличие еще двух.

    Кстати, как там с заменой Adaptive Endianess как в ZFS? Могу ли я использовать диски с btrfs, созданной на big-endian системе, на little-endian?

    И есть ли там экспорт блочных устройств, аналог ZVOL в ZFS?

    ОтветитьУдалить
  4. Анонимный4/08/2009 5:57 ДП

    Устаканился ? Наркотики это плохо !

    ОтветитьУдалить
  5. @Анонимный 1
    Спасибо за информацию :)

    @Aнонимный 2
    > А Extended Attributes?
    Тоже.

    > Защита от потери данных.
    Речь идёт о контрольных суммах.

    > Спасло только наличие еще двух.
    Там сказано _как минимум_ по одной на устройство, можно и больше.

    > как там с заменой Adaptive Endianess как в ZFS?

    Специально спросил на #btrfs. Говорят - не стали реализовывать, решили что не очень-то и нужно.

    > аналог ZVOL в ZFS?
    Насколько я понимаю - нет. Вместо этого можно просто монтировать разные подтома, указывая опцию -o subvol=name.

    ОтветитьУдалить
  6. Анонимный8/25/2009 10:33 ДП

    Этот комментарий был удален администратором блога.

    ОтветитьУдалить
  7. Анонимный11/07/2009 6:13 ПП

    Этот комментарий был удален администратором блога.

    ОтветитьУдалить
  8. Этот комментарий был удален администратором блога.

    ОтветитьУдалить
  9. Этот комментарий был удален администратором блога.

    ОтветитьУдалить
  10. Анонимный2/11/2010 2:06 ДП

    Этот комментарий был удален администратором блога.

    ОтветитьУдалить
  11. "Одна из особенностей современных ФС не так давно вызвала небольшой скандал... при использовании современных ФС (в той новости речь шла про ext4, но теми же свойствами обладают и XFS, и Btrfs, и многие другие) интервал между записью данных в страничный кэш и их записью на диск может достигать 150 секунд (больше двух минут)... при использовании на менее надёжном оборудовании нужно просто перенастроить ядро средствами sysctl, чтобы заставить pdflush срабатывать чаще."

    -- На самом деле это касается не только самой ФС и pdflush, но и умолчаний ядра, затрагивающего опции монтирования даже старой доброй ext3, -- умолчательные параметры которого в 2.6.30.5 изменились с data=ordered на data=writeback (см скажем здесь: http://lwn.net/Articles/325921/ http://www.mail-archive.com/linuxkernelnewbies@googlegroups.com/msg01904.html и здесь: http://www.opennet.ru/docs/RUS/fs/l-fs8_ru.html) Таким образом, всякий юзер, не заня этого и пользуясь с некоторых пор (навскидку с лета 2000) каким-то из "модерновых" дистросов (на ядрах начиная с 30-ки), сущекственно рискует своими данными. Конечно, если нет упса и он/она в своей ОС не вернули взад "консервативные" настройки опций монтирования (т.е. опцию data=ordered в команде tune2fs) хотя бы для раздела /home (или иного существенного с точки зрения пользовательских данных)...

    А вот все аргументы, которые обычно приводят типичные линупсятники, включая аргументы проблем с огнелисом (применительно заметим к линуху: по указ. ссылкам был озвучен), не выдерживают критики именно с системотехнического уровня рассмотрения. Это лишь ещё в 1001 лишний раз подтверждают "убогость" и непродуманность системотехнической концепции линукса в цедлом, и его ФС в частности. Впрочем, понятно откуда это пошло: даже изначельно в *никсах вообще ФС -- это было "слабое место"... но не слишком впрочем существенное когда-то, ДО эпохи распространения *никсов на десктопные и главное -- "широкоюзерские" приложения...

    ОтветитьУдалить
  12. Note. (Для "танкистов".) Этот так, потому что для серверов скоростные факторы ФС конечно важны, но зато там нет такого "разброса" в удовлетворении реальных нужд при той чертовой хуче взамиоисключающих факторов, как в случае проектирования ОС, ориентированной уже на сугубо десктопные применения. Поясняю: это весьм существенно в современных условиях при исключительной ориентации на гуй и к тому же несущего чертову же хучу разных приложений, которые подчас заюзают ФС ПК по максимуму. Притом, фактически требуя, -- для обеспеченния экранного, зрительного комфорта юзверя, -- чуть ли не свойств realtime ОС. Да, и под никсами тоже, что не так просто обеспечить в существующей архитектуре. А когда этого нет в ОС, юзверь законно недоволен разного рода "фризами", особенно часто наблюдаемыми именно под линухом, разного рода визуально неприятной "малокадровости" и "провалов" в перерисовке гуйной картинки: и юзверь в этом АБСОЛЮТНО прав!..

    Далее, -- "большая задержка записи является не недостатком, а преимуществом: это даёт возможность разместить данные более удачно, и избежать фрагментации" -- это сомнительное утверждение, основанное на типичнейших технократитческих побасенках и стереотипах. Достаточно упомянуть, что даже в наисовременнейших ФС мира *никс НЕ ИСПОЛЬЗУЮТСЯ разграничения по уровню приоритетов на кеширование различнх групп данных, включая "системные", в практически любой нынешней дисковой ФС (!!!). При таком положении вещей (замечу: с точки зрения технической целесообразности странном, ибо это легко с технической стороны вопроса поправимо, -- но это объясняется лишь убогостью, консервативностью, огрниченностью мышления преловутых "разрабов", особенно из сектора FSF&OpenSoft) ни о какой эффективности работы любой современной, а сугубо "десктопной" особенно, ФС не может быть и речи.

    К сожалению, я не имею возможности для развернутого разбора этой стороны дела в мире ФС. Нет у меня давным-давно и особого желания делать этого "профессионально", т.е. обращаясь к "широкой общественности" даже в интернете. Ибо по многолетнему опыту знаю, насколько трудно пробить ментальную стенку приверженности технократически настроенных умов ко всему "традиционному", привычному, давно устоявшемуся и кажущемуся понятным; но особенно мешает этому стереотипность восприятия чего-либо типичных технократов...

    Так что, вам, молодым, призыв: "Имеющий уши да услышит" (с)
    (...но увы знаю по опыту, что по факту происходит как всегда: "глас вопиющего в пустыне"...)

    WBR, Abnormal Terminate(R)

    ОтветитьУдалить
  13. Поправка: "с лета 2000" читать "с лета 2009" :)

    ОтветитьУдалить