| Каталог документации / Раздел "Документация для Linux" / Оглавление документа |
| |
|
Daniel Robbins ([email protected])
President/CEO,
Gentoo Technologies, Inc.
December 2001
С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. В этой статье Daniel продолжает рассматривать ext3, новую улучшенную версию файловой системы ext2 с возможностью journaling. В статье вы найдете описание режимов ext3 и демонстрацию некоторых неожиданных ext3 data=journal показателей интерактивной производительности.
Я хочу быть честным. В этой статье я планировал описать установку и настройку ext3 на вашей системе. Хотя такая цель была обозначена, это не совсем то, о чем пойдет разговор. У Andrew Morton's имеется превосходная "Using the ext3 filesystem in 2.4 kernels" страница (смотри Resources далее), что делает простое объяснение перехода на ext3-enable излишним (зачем повторять то, что прекрасно описано у других). Вместо этого я собираюсь обратить ваше внимание на неожиданные стороны использования ext3 и, думаю, это будет полезным для вас. После прочтения этой статьи вы будете готовы к более осознанному переходу на ext3, чем в случае "пересказа" Andrew's page. По крайней мере, я на это надеюсь.
Давайте начнем с ядра. Я обсуждал стабильную 2.4 ветку, когда описывал ReiserFS. При написании той (часть 2) статьи я рекомендовал остановиться на одной из последних к тому времени 2.4.4-ac9 версии ядра. В то время эту версию можно было рекомендовать как наиболее приемлемую для использования ReiserFS в промышленной среде. Поскольку с того времени утекло много воды и 2.4.4-ac9 уже не новость, пришло время сказать несколько слов о более современных версиях.
С появлением 2.4.10 серия 2.4 вышла на новый уровень производительности и универсальности (а вопросы были). Что же такое принципиальное случилось, что позволило Linux 2.4 выйти из кризиса? В акрониме к VM Linus признал, что серия 2.4 не оправдала надежд, и, прежде всего, из-за проблематичного кода VM. Первоначальный код поменяли на неотработанную и среднюю VM реализацию от Andrea Archangeli. Новая VM реализация от Andrea (впервые появилась в 2.4.10) стала действительно большим шагом вперед. Производительность ядра реально увеличилось, а система стала более чувствительной. 2.4.10 определенно поворотный пункт в развитии ядра 2.4 Linux. До этого момента оптимизм понемногу таял, и возникали вопросы, а не примкнуть ли к команде FreeBSD developers. Нужно отдать должное Linus за его решительность к таким серьезным (но необходимым) изменениям в стабильной ветке.
После такого поворота событий и включения нового VM кода от Andrea требуется немало времени для "затирания швов" (вопросы стабильности вышли на первый план). Используйте ядра 2.4.13+, а лучше 2.4.16+ (но не между ними) для rock-solid ext3. Код был интегрирован в ядро (без patch) начиная с версии 2.4.15-pre2. Нет оснований избегать использования 2.4.16+ ядра, с ним реализация ext3 будет полной. Когда будете читать Andrew's page (смотри Resources дальше), имейте в виду, начиная с 2.4.16 нет надобности накладывать patch на ядро (это уже сделано).
Обратите внимание, я рекомендую использовать 2.4.16+ (даже 2.4.13+), но не 2.4.15+. На это есть серьезные основания. В релизе 2.4.15-pre9 был обнаружен ugly filesystem corruption bug. Выбор 2.4.16+ ядра избавит вас от возможных проблем.
Предостережение пользователям laptops.
Ext3 имеет твердую репутацию rock-solid filesystem, и я с удивлением узнал, что у нескольких пользователей laptop возникли проблемы при переходе на ext3. Был соблазн, как реакция на подобные сообщения, отказаться от использования ext3. Однако, разбираясь в причинах таких явлений, я обнаружил, что проблемы не связаны непосредственно с ext3, а были вызваны laptop hard drives.
Вы можете этого и не знать, но самые современные hard drives имеет нечто, называемое "write cache". Он используется hard drive для сбора ожидающих обработки операций записи. Помещая ожидающие обработку записи в кэш, hard drive firmware может переупорядочивать и группировать их так, чтобы они были записаны на диск самым быстрым из возможных способов. Кэш записи с такой позиции очень полезная вещь (читайте объяснение Линуса и его мнение о write caching в разделе Resources).
К сожалению, некоторые laptop hard drives имеют сомнительную возможность игнорирования любого "официального" ATA request с требованием сброса на диск их write cache. Возразить нечего, такая "замечательная" feature до недавнего времени не была запрещена ATA спецификацией. При взаимодействии с такими типами дисков у ядра нет возможности гарантировать, что специфический блок был "фактически" сброшен на диск. Хотя это необходимая причина вдруг возникшей проблемы с нарушением целостности данных, но еще не достаточная.
Ситуация оказалась еще хуже. Некоторые современные laptop hard drives имеют еще более "вредную" привычку без команды сбрасывать свой write cache, когда система перезагружается или "засыпает". Если hard drive наделен обеими features, а файловая система поддерживает журнализацию, происходит периодическое разрушение данных и нельзя ничего предпринять для предотвращения этого.
Где решение? Если вы имеете laptop, действуйте осторожно. Сохраните важные файлы перед внесением больших изменений в файловую систему. Если возникнут проблемы с нарушением целостности данных после перехода на ext3, возможно причина в "продвинутости" вашего диска. В таком случае можно войти в контакт с изготовителем вашего laptop hard drive по вопросу о его замене. Есть надежда, что уже в ближайшее время эти диски уйдут с рынка (или переместятся на рынки третьих стран - прим. переводчика) и о проблеме можно будет забыть.
Теперь, после испуга, вы готовы к обсуждению различных ext3 опций journaling данных.
Опции journaling и производительность.
Ext3 предлагает на выбор три режима journaling при монтировании файловой системы:
data=writeback, data=ordered и data=journal.
Для указания journal mode можно добавить соответствующую строку (например,
data=journal) в поле опций записи в /etc/fstab или
непосредственно в командной строке указать -o data=journal при вводе
команды mount. Для указания метода journaling на root файловой
системе (по умолчанию data=ordered) можно использовать специальную
kernel boot option, называемую rootflags. Например, для указания
монтирования корневой файловой системы в режим full data journaling, добавьте
rootflags=data=journal к kernel boot options.
В режиме data=writeback, файловая система ext3 не выполняет какого
либо журналирования data. С подобным видом журналирования вы имеете дело в
файловых системах XFS, JFS и ReiserFS (metadata only). Как объяснялось в
предыдущих статьях, это не защитит от разрушения
данные в обновляемых файлах в случае неожиданной перезагрузки. Несмотря на этот
недостаток, режим data=writeback обеспечивает самую высокую
производительность ext3 при всех условиях.
В режиме data=ordered файловая система ext3 "официально" журналирует
только метаданные, но логически metadata и data блоки группируются в единый
модуль, называемый transaction. Перед записью новых метаданных на диск, связанные
data блоки записываются первыми. Режим data=ordered эффективно
(хотя без гарантии) решает проблему c разрушением данных, свойственную режиму
data=writeback и большинству других journaled файловых систем.
Заметьте, делается это без full data journaling. По производительности следует
заметить, что data=ordered в ext3 работает несколько медленнее
data=writeback, но заметно быстрее full data journaling.
Что касается гарантии от разрушения данных. При добавлении данных в конец файла
режим data=ordered гарантированно обеспечивает целостность (как при
full data journaling mode). Однако если данные в файл пишутся поверх существующих,
то есть вероятность перемешивания "оригинальных" блоков с модифицированными.
Это результат того, что data=ordered не отслеживает записи, при
которых новый блок ложится поверх существующего и не вызывает модификации
метаданных. В режиме data=ordered порядок записи отслеживается только
до попадания в hard drive's write cache. Такое ограничение не должно огорчать
пользователей, так как операция добавления в конец файла более обычна, чем
наложение записи. По этой причине режим data=ordered хорошая
альтернатива для full data journaling.
Режим data=journal обеспечивает полное журналирование и метаданных,
и самих данных. Все новые данные сначала пишутся в журнал и только после этого
переносятся на свое постоянное место. В случае аварийного отказа журнал можно
повторно перечитать, приведя данные и метаданные в непротиворечивое состояние.
Теоретически, режим data=journal самый медленный из всех journaling
режимов, так как данные записываются на диск два раза. Однако было доказано, что
в отдельных случаях режим data=journal показывает неплохие результаты.
Andrew Morton, после знакомства с отчетами LKML о том, что в ext3
data=journal иногда неожиданно выдает высокую производительность,
решил провести небольшое тестирование. Сначала он написал простой shell script,
предназначенный для записи данных на тестируемую файловую систему с максимально
возможной скоростью:
while true
do
dd if=/dev/zero of=largefile bs=16384 count=131072
done
Одновременно с записью данных на тестируемую файловую систему, он попытался прочесть 16Mb данных с другой ext2 файловой системы того же диска, подсчитав результаты:
Чтение 16Mb файла.
time cat 16-meg-file > /dev/null
Результат оказался поразительным. Режим data=journal позволил
прочесть 16Mb файл в 9 - 13 раз быстрее, чем при других ext3 режимах, ReiserFS и
даже ext2 (в которой журналирование вообще отсутствует):
data=ordered
93
data=writeback
74
ext3 data=journal
7
Эндрю повторил тестирование, изменив условия. Чтение 16Mb файла происходило с
тестируемой файловой системы. Результат оказался аналогичным. Что из этого
следует? Так или иначе, но режим data=journal очень хорошо подходит
для случаев, когда данные должны одновременно читаться и записываться. Поэтому
режим data=journal, который теоретически считался самым медленным,
оказывается, имеет преимущество в среде, сильно нагруженной интерактивными
операциями IO. По крайней мере, режим data=journal не настолько вял,
как казалось бы!
Andrew еще не нашел объяснений, почему так происходит. Возможно, ответ на этот
вопрос поможет в совершенствовании ext3 так, чтобы режимы data=writeback
и data=ordered стали более производительными.
Сообщалось о специфической проблеме при использовании ext3 в режиме
data=journal на нагруженных серверах и нагруженных NFS серверах в
частности. Каждые тридцать секунд сервер испытывает "шторм записей" на диск,
прекращая реагировать на все остальное. Если вы столкнулись с такой проблемой,
ее можно устранить. Введите следующую команду (с привилегиями root) для
"подстегивания" Linux's dirty buffer-flushing algorithm:
echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush
Такая настройка bdflush заставит kupdate выполняться каждые 0.6 секунд, а не через 5 секунд (по умолчанию). Кроме того, ядру сообщается необходимость сброса на диск dirty буфера через 3 секунды, а не через 30 (значение по умолчанию). Регулярно и часто сбрасывая на диск недавно измененные данные, можно избежать затяжных "штормов записи". Помните, это снизит эффективность работы (особенно при небольшой загрузке системы), так как у ядра будет меньше возможностей для объединения операций записи. Нагруженному серверу снижение эффективности не грозит, а интерактивность будет улучшена.
Об ext3 хватит. Приглашаю к чтению моей следующей статьи, поскольку речь пойдет о многих чудесах ... XFS!
Residing in Albuquerque, New Mexico,
Daniel Robbins is the President/CEO of
Gentoo Technologies, Inc., the creator of Gentoo Linux, an advanced Linux for the PC,
and the Portage system, a next-generation ports system for Linux. He
has also served as a contributing author for the Macmillan books
Caldera OpenLinux Unleashed, SuSE Linux
Unleashed, and Samba Unleashed. Daniel has been involved with computers in some fashion since the second grade,
when he was first exposed to the Logo programming language as well as a
potentially dangerous dose of Pac Man. This probably explains why he has since
served as a Lead Graphic Artist at SONY Electronic Publishing/Psygnosis.
Daniel enjoys spending time with his wife, Mary, and their daughter, Hadassah. You can contact Daniel at [email protected].
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |