Материал из Linuxformat.

Супер-Тед

Знакомьтесь – Теодор Цо: работает с ядром аж с 1991 (!). Поклонник Баффи – истребительницы вампиров, а по совместительству хранитель наших данных.

Крах файловой системы — настоящая катастрофа, и разработчики ext4 трудятся не покладая рук, чтобы свести наши потери к минимуму. Словно супергерой файловой системы Linux, наш гость стоит на самой высокой крыше и непрерывно сканирует наш с вами город точными fsck. Встреча произошла на OSCON 2009: тут мы и узнали, кто хозяин всех наших файлов…

Linux Format: Все знают, что вы — один из ключевых разработчиков ext4, но в чем конкретно состоит ваша роль?

Тед Цо: Я главный ответственный за подсистему (maintainer). Курирую вопросы контроля качества и проверки на ошибки кода, созданного другими людьми, перед включением его в ядро. Очень часто моя работа сводится к тому, чтобы сказать: «Это не имеет смысла – я этого не понимаю».

LXF: Вы говорите так, а остальные думают: «Я что, совсем дурак?»

ТЦ: В том-то и беда, что многие становятся в позу: «Но это же работает!» – ведь никто не любит признаваться в непонимании. Я должен смотреть на код, написанный другим человеком, и понимать его в достаточной мере, чтобы описать. Для некоторых наших программистов английский язык не родной: разобрать их комментарии к коду и описания заплат порой бывает нелегко. Так что работы полно, и не самой приятной, но от этого никуда не денешься, потому что через полгода никто не будет помнить, зачем добавляли ту или иную заплату, и если мы сразу как следует ее не опишем – затем, шесть месяцев спустя, с этим будет не разобраться.

Для успешной разработки файловой системы необходимо, чтобы в Red Hat и SUSE работали люди, знающие, что к чему: ведь им предстоит обеспечивать поддержку в дальнейшем.

Google, например, живо интересуется вопросами, связанными с файловой системой, и постоянно работает над совершенствованием и развитием существующих механизмов.

LXF: А что, Google тоже использует ext4?

ТЦ: О да. Мы получаем от него мощную поддержку в работе с режимом, который мы называем «нежурналируемым». Процедура, используемая Google для восстановления ФС после краха, начинается с тотального форматирования: ведь там постоянно поддерживается три копии данных, причем на уровне приложений. Поэтому журнал для них не имеет особой ценности, fsck тоже не пользуются. Специалисты Google заметили, что при переходе с ext2 на ext4 (без журнала) получается заметный прирост производительности. Ну, а для нас сотрудничество с ними означает дополнительное тестирование и помогает находить нетипичные ошибки.

Мы держим связь с сотрудниками Red Hat, продвигающими ext4 на Fedora, а там набор вопросов, связанных с разработкой и тестированием, совершенно другой. Вот так и получаются действительно хорошие файловые системы: если ее разрабатывать, исходя только из своей личной перспективы, легко уклониться в слишком узкую специализацию.

LXF: А что вы можете сказать о ZFS? Ведь одна из целей файловой системы Tux3 — превзойти ее. Черпаете ли вы вдохновение в других ФС?

ТЦ: Ну, Btrfs, в частности, намерена переплюнуть ZFS, и многим это не слишком нравится. Должен сказать, что Sun во многом вдохновила работы над файловыми системами, которые раньше велись просто в режиме технической поддержки. Потому что с точки зрения рабочей нагрузки файловую систему не назовешь участком, от которого зависит производительность приложения. Многие программы, например, используют базы данных: от MySQL производительность действительно зависит, а файловая система работает только при загрузке приложения.

LXF: А Oracle разве не разработала собственную ФС?

ТЦ: Верно. С точки зрения создателя файловых систем базы данных обладают одной интересной особенностью: в процессе работы они отстраняют ФС, чтобы не мешала. Действительно, единственная причина, по которой базы данных вообще терпят ФС – это желание пользователя, которому удобнее помещать базу в некую систему. Все наиболее крупные и известные базы данных используют в работе прямой доступ к дисковым устройствам, в обход файловой системы. Проблема только в том, что в таком режиме можно перепутать устройства, да и резервное копирование усложняется. Поэтому сисадмины не любят работать с прямым доступом к дискам: он разве что повышает результаты сравнительных тестов.

LXF: А каково ваше общее впечатление от ZFS?

ТЦ: Один из ее существенных недостатков – плохая совместимость с базами данных: стандартная конфигурация этой системы противоречит интересам БД. Но даже если изменить настройки по умолчанию, то – как мне говорили – невозможно контролировать или ограничивать переменный размер блоков ZFS на «пофайловой» основе. Придется либо установить размер блока 4К, что нейтрализует многие достоинства системы, либо размер будет меняться. И если размер будет, например, равен 128К, то при изменении крохотного участка файла придется заново переписывать все 128 КБ. Поэтому я считаю, что при создании ZFS недостаточно учитывалась совместимость с базами данных. Либо вы разместите базу непосредственно на дисковом устройстве, либо махнете рукой на быстродействие. Если отложить в сторону успешные компании Web 2.0 (с их миллионами обращений в час), то вообще-то немало таких работ, для выполнения которых сверхпроизводительность вовсе не нужна. Но ведь люди, стремясь приобрести все «самое-самое», смотрят на сравнительные тесты. Это напоминает спортивные автомобили: мало кому удается разогнать его по максимуму, но каждый старается купить авто помощнее.

Любой специалист по файловым системам (особенно если рядом нет маркетолога) охотно объяснит: «Да, для данного рода работ наша ФС не бьет рекордов. Это потому, что мы пошли на инженерный компромисс и, поступившись быстродействием, выиграли во всем прочем». Только вот на роль лозунга это высказывание не годится. Людям нравится твердить: «ZFS – последнее слово в развитии файловых систем!»

LXF: И это отличный слоган!

ТЦ: Ну да. Но по сути это неправда. LXF