Совсем недавно Джефф Лэйтон взял интервью у Валери Авроры – разработчика файловых систем и евангелиста открытого кода. Поговорили на весьма широкий круг тем, включая её вклад в различные файловые система, о ChunkFS и Union file system, об экосистеме разработчиков файловых систем.

Есть много авторитетных людей в мире Linux. О многих знает и широкая публика, но многие остаются в тени и известны только в очень узком кругу. Валери Аврора – лидер мнений не только среди разработчиков Linux, но и в среде свободного и открытого программного обеспечения в целом. Она сделала весомый вклад в разработку ChunkFS и в разрабатываемую в данный момент Union file system для Linux ядра.

В течение нескольких последних лет разработка файловых систем для Linux напоминала болото. Сообществу хватало ext2 и ext3. Конечно, предпринимались попытки внести что-то новое с разработкой ReiserFS, но в целом разработка файловых систем в сообществе остановилась. Валери, понимая опасность такого застоя, организовала первый Linux File Systems Workshop (семинар, посвященный файловым системам для Linux). Кроме того она отметилась участием в Fast09.

Именно при её непосредственном участии сообщество осознало необходимость в продолжении разработки файловых систем. Представление об этом и о неслучайности её появления с такими идеями можно получить зайдя на её сайт (на английском).

Джефф Лэйтон Пожалуйста, представьте себя, расскажите немного о своей деятельности и о том, чем вы занимаетесь в данный момент.

Валери Аврора Я выросла в Нью-Мексико (такой штат между Техасом и Аризоной), выпасая коз и выращивая лошадей. Образование моё было нерегулярным, до такой степени, как это может быть у наименее религиозного ребёнка в округе, учащегося дома. Но при этом оно было достаточным для поступления в “не очень крутой” технический университет Нью-Мексико. Я получила диплом по специальностям компьютерные науки и математика и получила свою первую работу программиста, прочитав объявление в разделе “Требуется помощь” в журнале Albuquerque (самая крупная ежедневная газета штата).
На сегодняшний день я живу в жилом комплексе в деловой части Сан Франциско с двумя котами и Roomba. Будучи уникальной индивидуальностью, работаю неполный рабочий день в Red Hat, как разработчик файловых систем, а также как научно-популярный писатель и консультант по вопросам, связанным с Linux. Мне нравится иметь больше одной работы; скука – этой мой злейший враг и новое занятие каждую неделю удерживает меня в заинтересованном состоянии и развлекает.

ДЛ Вы упомянули свою работу над файловыми системами, можно поподробнее рассказать о своей деятельности в этой области? В частности, над каким файловыми системами Вы работали? Какие Вам нравятся больше всего и почему? (Всегда полезно узнать, что же используют настоящие профессионалы)

ВА Наверное, это будет долго, но попробуем.
Я не была заинтересована в файловых системах до того момента, как я получила работу, связанную с разработкой одной из них – ZFS, в 2002. А так как я не очень много знала о файловых системах, я читала и перечитывала исследовательские статьи о файловых системах и посетила конференцию о файловых системах USENIX (ДЛ: Fast09 – последняя на сегодняшний день). В том малом числе хороших книг об операционных системах, которое я видела, говорится очень мало о файловых системах, и обычно описывается архитектура VFS в стиле Sun и дисковый формат типа FFS.
После SUN я перешла в IBM в группу Феодора Тс’О (Theodore Ts’o). Мы занимались в основном бесконечной поддержкой пользователей, что было довольно весело, так как в Sun мне вообще не приходилось общаться с клиентами. В свободной время я и Тед были поглощены безумными идеями добавить в ext2 и ext3 разные возможности, которые бы не требовали 20-30 лет для их разработки. В то время разработкой файловых систем для Linux занимались только в Namesys (компания Ганса Рейзера), и их бизнес-модель не казалось очень жизнеспособной.
Затем я перешла в Intel и у меня появилось время, чтобы воплотить все эти сумасшедшие идеи и прийти к множеству новых. Одной из них был грязный бит ext2, который позволял пропускать проверку после краха системы, если файловая система в тот момент находилась в режиме ожидания. Другой такой идеей было условное обновление времени последнего доступа, что теперь, три года спустя, является стандартным поведением системы. Обсуждая с Арианом ван де Веном вопрос, почему идея с грязным битом не сработала при групповой блокировке блоков системы, мы пришли к идее ChunkFS, над которой я и начала работать.
Это казалось бессмысленным, но при этом, как же Linux может оставаться конкурентоспособным в отсутствие разработчиков, работающих над файловыми системами для него полный рабочий день? Таким образом, вместе с Захом Брауном и Арианом, мы организовали первый малобюджетный семинар о файловых системах в Linux, державшийся на скотче, в надежде, что просто общение между существующими разработчиками файловых систем может привести нас к пути увеличения финансирования этой области. Не знаю, принесло ли это какую-то пользу, но если это так, то это можно назвать моим самым важным вкладом с разработку файловых систем для Linux.
Тогда я начала свой консультационный бизнес и сделала довольно много для chunkfs и ext2/3/4 (распараллеливание fsck), а сейчас работаю в Red Hat. В данный момент я работаю над union mounts вместе с Яном Бланком(Jan Blunck), это основанный на VFS подход к соединению различных файловых систем.
На своих компьютерах я всегда использую систему ext3 с опцией noatime, или относительным atime, если он доступен. Также я отключаю параноидальные проверки файловой системы командами “tune2fs -i 0″ и “tune2fs -c 0″. Еще я отключаю SELinux, который активно использует расширенные атрибуты да и вообще является весьма спорной технологией. Сейчас для моей работы над 64-битной версией ext4 я создаю большие распределенные 16TB+ файлы в XFS и монтирую уже их для получения устройства объемом 16TB+. (Вы, конечно, можете сделать это на ext4 при помощи md, но усилия не стоят того). В общем я использую ext3 как основную систему и XFS, если ext3 не может сделать то, что мне нужно. Когда я перейду на другую файловую систему, это будет btrfs.
После выходы 2.6.30 я также начала добавлять опцию data=ordered, так как сейчас базовое поведение для ext3 это data=writeback, что может вылиться в гаденькие повреждения файлов во время краха системы.

ДЛ Вы упомянули переход на btrfs. Люди всегда интересуются сравнениями между btrfs и ZFS и дискуссия обычно принимает очень острый оттенок, но может быть Вы скажете нам своё мнение об этих двух системах? Предполагаете ли Вы в ближайшем будущем какую-либо систему, которая будет “лучше” чем btrfs или ZFS (можете понимать под “лучше” что угодно).

ВА Почему-то файловые системы превратили всех нас в фанатиков. В старые времена, я поняла, что фанатизм – это очень утомительное дело, поэтому я предпочитаю конкретные факты.
ZFS и btrfs похожи как по структуре так и по целям. Общими свойствами можно назвать копирование при записи, контрольные суммы, изменяемые снапшоты, пулы для хранения информации, простое администрирование и еще много всего очень обсуждаемого в сообществе. При этом более интересны различия в архитектуре.
На самом высоком уровне ZFS использует концепцию плоских деревьев из указателей на блоки, стиль FFS и переменный размер блока, навеянный планировщиком памяти ядра SLAB. Btrfs использует использует дружественные к COW (копирование при записи) B-деревья (в том виде, в каком это представлено Охадом Родехом (Ohad Rodeh) на LSF ‘07) и экстенты. На самом деле btrfs ещё немного лучше, чем можно подумать: каждый кусок данных или метаданных в btrfs – это объект в B-дереве, и эти объекты группируются вместе вперемешку – без оглядки на их тип. ZFS сужает абстракцию всех метаданных и данных до объектов и относящихся к ним операций; btrfs сузила эту абстракцию до листьев B-дерева. После этого самым интересным стало решение проблемы присвоения ключей объектам этого дерева и их упорядочения.
Ну и сейчас я могу сказать своё личное/фанатичное мнение. С самого начала, я думала, что подход ZFS был проще и чище – в то время код для управления B-деревьями и экстентами был очень усложнён и добавление к нему копирования при записи и контрольных сумм скорее всего привело бы к взрыву мозга. Но после того, как Охад Родех упростил реализацию и сделал её более надёжной, а Крис Масон (Chris Mason) представил свою концепцию “всё есть лист дерева”, моё мнение изменилось. Я неофит этого подхода.

ДЛ Недавно на lwn была статья о ChunkFS. Для наших читателей можете кратко о ней рассказать? Предпринимались ли усилия по включению идей из ChunkFS в другие файловые системы?

ВА Я хочу отметить две вещи: (1) файловые системы всегда повреждаются, (2) время, требующееся на проверку и восстановление “средней” файловой системы продолжает расти, в следствие продолжающейся эволюции железа. Chunkfs – это больше интересная концепция, чем законченная архитектура; основная идея состоит в том, что файловая система может быть разделена на множество независимых частей, которые могут быть проверены и восстановлены в случае повреждения практически безотносительно других частей системы. Проверка (fsck) благодаря этому превращается из длительной болезненной процедуры, требующий отключения всей системы на часы, в постепенный процесс, проводимый в фоновом режиме и на живой системе. Мы создали прототип и пришли к выводу, что (а) идея работает, (б) разделение файловой системы на независимые части должно предполагаться дизайном архитектуры с самого начала разработки, чтобы принести какой-то результат.
С тех пор, как chunkfs была разработана, было спроектировано немного систем, в основном btrfs и Tux3 (и HAMMER, но я не думаю, что они учитывали наши идеи). Я не знаю насколько chunkfs повлияла на другие файловые системы, но я знаю, что обратные указfтели в btrfs – например, каждый блок данных имеет указатель на относящиеся к нему метаданные – были вдохновлены chunkfs.

ДЛ Я читал Ваши статьи UnionFS на lwn, и они мне действительно нравились. Расскажите об основных концепциях, использованных в UnionFS, и насколько они могут быть полезны (или не могут) и в каких ситуациях они себя хорошо проявляют?

ВА Идея соединения пространства имён двух файловых систем витала в воздухе последние десять лет. В Plan 9 она была реализована кроме всего прочего, чтобы исключить необходимость в множестве переменных окружения вида *_PATH, перечисляющих нужные приложения, библиотеки, документацию и т.д. – все возможные директории были соединены в одну. Подход из Plan 9 был ограничен и не учитывал некоторых частностей – он применялся только к отдельным директориям, не ко всей файловой системе, невозможно было задать различный порядок поиска для разных приложений, не исключалось дублирование и др. – но этот подход обеспечил чувство уверенности в нужности объединения пространств имён. Я обнаружила, что когда у вас есть метод объединения пространств имён, он очень быстро превращается в молот и множество проблем неожиданно становятся гвоздями (даже если на самом деле они являются шурупами или винными бокалами). Концепция очень мощная и её можно использовать, чтобы заменить очень крупные наслоения в ядре UNIX и в пользовательских приложениях (посмотрите хотя на путь поиска в Plan 9) и встаёт не вопрос “Могу ли я решить эту проблему объединением?”, а “Является ли объединения лучшим путём для решения проблемы, или есть и более хороший способ?” Одним из случаев, когда объединение оказывается самым лучшим путём, является поддержка изменяемого слоя на системе только для чтения. Для решения этой задачи существует два конкурирующих решения: одно состоит в работе с подмонтируемыми файлами и папками для записи, когда они требуются, или замена их симлинками на записываемую файловую систему примонтированную где-то в том же адресном пространстве (Я это делала – это на самом деле еще хуже, чем кажется на слух), другим решением является использование блочного устройства, реализующего копирование при записи (COW). Такое COW-блочное устройство – это разумное решение решение для таких ситуаций, как корневая файловая система для множества виртуальных машин, запущенных на одном хосте, но она работает отвратно с длительно подключенными клиентами, или тонкими клиентами, получающими доступ к своим базовым системам в режиме чтения через сеть.
Одним из случаев, когда объединение не является оптимальным решением есть необходимость быстро подключить снимок файловой системы с конкретным набором программ и конфигурационных файлов. Занятие этим вручную превращается в муку; Вам нужно запустить установщик, выбрать необходимые пакеты, затем вручную выправить все конфигурационные файлы для локальной сети, пользователей и всего остального. Подход с объединением предполагает создание строительных блоков для файловой ситемы, которые могут быть соединены вместе и содержать необходимые наборы программного обеспечения. Например, у вас будет базовый снимок файловой системы сервера, слой с файлами, требующимися для запуска SMTP сервера, еще один слой со всеми файлами, требующимися для Apache и так далее, и потом вы соединяете вместе нужный набор файловых систем с желаемым программным обеспечением и надстраиваете слой с возможностью записи поверх всего этого. Ура, теперь всё вместе, да?
Практически первое и очевидное возражение восходит прямо к сердцу проблемы, почему объединение является плохим решением: RPM/apt/любая другая база установленных программ будет различной для каждого набора установленного ПО, а объединение даст вам только один единственный файл из самого последнего слоя, который будет содержать только информацию о пакетах, установленных в этом последнем верхнем слое. Таким образом если вы установите postfix в один слой, а Apache в другой, и объедините их, ваша система управления пакетами будет знать только об одном из них, а не об обоих. Поэтому ваша попытка решить проблему с установкой ПО и его конфигурацией при помощи файловых систем вряд ли будет работать. Вместо этого вам нужно что-то наподобие Puppet, который не только автоматизирует установку и настройку систем таким образом, что вы можете быстро создать специализированный снимок диска; также он предоставляет все возможные бонусы от систем управления пакетами и конфигурациями, такими как проверка, что /etc/passwd не был изменён руткитом, или что ваш новый стажирующийся системный администратор не настроил почтовый сервер на принятие всех входящих соединений.
Если вы обратитесь к истории объединения файловых систем, вы увидите, что его пытались использовать для реализации управления исходным кодом. Просто установите дерево кода ядра, примонтируйте к нему слой для записи и записывайте всю свою разработку туда. А когда закончите – создайте диф (файл с разницей) к оригиналу. В эпоху git, Mercurial, SVN и великого множества других полнофункциональных систем управления исходным кодом, которые у нас есть, это выглядит крайне смешно. Но во времена, когда всё что у нас было это CVS, SCCS и RCS, объединение файловых систем казалось заманчивым путём реализовать систему контроля версий, уж так низок был уровень существующих. Я думаю, что управление программным обеспечением и его настройка находятся сейчас приблизительно на том же уровне, в процессе перехода от старого мира паршивых утилит, которые приносят больше головной боли, чем решают проблем, к новым удобным средствам, которые определенно лучше, чем любой хак с файловой системой.

ДЛ Какие-нибудь комментарии о распределённых и/или распараллеленных файловых системах?

ВА У меня есть хорошо отрепетированный ответ на практически любой вопрос о распределённых файловых системах: вы не можете оптимизировать распределенную файловую систему для любой возможной задачи, поэтому найдите файловую систему, оптимальную для такой задачи, какая стоит перед вами – и используйте её только для этой задачи. Этот совет относится и к разработчикам распределённых файловых систем: не пытайтесь сделать свою систему лучшей во всём, нацельтесь на определенную задачу и оптимизируйте свою систему под неё. То есть, если вы хотите разместить базу данных Oracle на кластере с разделяемыми дисками, используйте OCFS2. Если перед вами стоит задача наподобие MapReduce, используйте Hadoop. Если вы предполагаете очень массивный параллельный ввод/вывод в файлы с данными, используйте Lustre. Если вам нужна хорошая производительность при единственном процессе на запись и множестве читающих, используйте NFS. Ну и так далее.
Я думаю такой комментарий является бегством от проблемы – но я просто не настолько заинтересована в распределённых файловых системах – и если посмотреть в его поглубже, он может оказаться очень и очень мудрым. И в конце концов он очень быстро избавляет меня от длинной и нудной дискуссии о распределенных файловых системах.

ДЛ С высоты Вашего положения как Вы видите будущее файловых систем после btrfs и ext4?

ВАОх! Я даже не задумывалась о том что будет после приходящего поколения файловых систем – я просто очень рада тому, что оно приходит, ведь было совсем не очевидно, что изменится хоть что-то еще в 2006 году. С оглядкой на локальные файловые системы, я думаю btrfs – достаточно гибкая, чтобы обработать любые изменения в железе в следующие 10 лет, как в производительности, так и в объёме – другими словами, работать с SSD (твердотельные накопители) и необычайно большими объёмами хранимой информации. Думаю, также мы увидим больше устройств основанных на flash, в случае чего LogFS и NILFS становятся гораздо более интересными, наверное как часть техники wear-leveling (техника продления жизни устройств хранения, в основном flash-памяти, путями ведения контрольных сумм, содержания пула неиспользованного места, упорядочения блоков памяти по интенсивности использования и др.) с открытым исходным кодом – слоя который может быть тесно интегрирован с другими файловыми системами Linux. На втором фронте – распределённых файловых системах, я слежу за Ceph. Её архитектор Сейдж Вейл знает своё дело и потратил несколько лет, чтобы создать правильный дизайн. На поле оптимизации задач вида “одна запись/множество чтений” в распределённых файловых системах CRFS внушает уважение, если вы можете выполнить требование использования btrfs, как локальной файловой системы (и вы должны это сделать).

ДЛ Ну и напоследок, что же может Linux сообщество сделать для поддержания разработки и эволюции файловых систем? И может быть какие-то комментарии о нашей беседе в целом?

ВА Я бы сказала, что нам не следует погружаться в самодовольство. Конкретная файловая система обычно хорошо себя проявляет в течение десятилетия, ну второго десятилетия, и деградирует до абсолютной невозможности её использования в третье. Идеально нужно начинать работу над следующей файловой системой в середине второго. Но если посмотреть на это с позиций разработчиков, то вы поймете, что к тому времени уже не будет разработчиков используемой системы, а работающие программисты не будут иметь соответствующего опыта разработки, потому что существующая файловая система просто работает. Менеджеры как правило не обладают достаточно долговременной памятью, чтобы понять, что программистам надо начинать работать уже сейчас, при том что результата не будет в ближайшие 5 лет, а то что будет ещё прекрасно работать в следующие 10 лет. Одна из прекрасных особенностей разработки Linux состоит в том, что у нас так много файловых систем в разработке, что нам легко поддерживать такую долговременную память, но всё равно Linux уже опоздал на несколько вечеринок файловых систем.

Я думаю гораздо интереснее поговорить о том, как не погрузиться в самодовольство… Надо постоянно общаться с разработчиками других файловых систем лично, экспериментировать с новыми файловыми системами, общаться с исследователями и академической средой, следить за новыми веяниями в разработке железа. Путём в обход позиции “файловые системы – это решенная проблема” состоит в постоянном контакте между собой и всем остальным миром.

Ну а мой общий комментарий, что ж, давать интервью гораздо веселее, чем писать статьи. 🙂 Спасибо за такую возможность.