пятница, 17 июля 2009 г.

Евангелист файловых систем и лидер мнений Валери Аврора - Интервью (часть 2)

Продолжение интервью, которое Джеф Лэйтон взял у Валери Авроры. (оригинал)



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

ВА Я хочу отметить две вещи: (1) файловые системы всегда повреждаются, (2) время, требующееся на проверку и восстановление "средней" файловой системы продолжает расти, в следствие продолжающейся эволюции железа. Chunkfs - это больше интересная концепция, чем законченная архитектура; основная идея состоит в том, что файловая система может быть разделена на множество независимых частей, которые могут быть проверены и восстановлены в случае повреждения практически безотносительно других частей системы. Проверка (fsck) благодаря этому превращается из длительной болезненной процедуры, требующий отключения всей системы на часы, в постепенный процесс, проводимый в фоновом режиме и на живой системе. Мы создали прототип и пришли к выводу, что (а) идея работает, (б) разделение файловой системы на независимые части должно предполагаться дизайном архитектуры с самого начала разработки, чтобы принести какой-то результат.
С тех пор, как chunkfs была разработана, было спроектировано немного систем, в основном btrfs и Tux3HAMMER, но я не думаю, что они учитывали наши идеи). Я не знаю насколько 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 уже опоздал на несколько вечеринок файловых систем.

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

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

1 комментарий:

  1. Анонимный17 июля 2009 г., 14:40

    спасибо за перевод.
    зря ее про похмел не спросили.

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