Руководство по продвинутым файловым системам
Неожиданности от ext3

Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука

Первоисточник: http://www-106.ibm.com/developerworks/library/l-fs8.html
Декабрь 2001

Зачем оно нужно?

Я хочу быть честным. В этой статье я планировал описать установку и настройку ext3 на вашей системе. Хотя такая цель была обозначена, это не совсем то, о чем пойдет разговор. У Эндрю Мортона (Andrew Morton) имеется превосходная страница Using the ext3 filesystem in 2.4 kernels, что делает простое объяснение перехода на ext3 излишним (зачем повторять то, что прекрасно описано у других). Вместо этого я собираюсь обратить ваше внимание на неожиданные стороны использования ext3 и, думаю, это будет полезным для вас. После прочтения этой статьи вы будете готовы к более осознанному переходу на ext3, чем в случае "пересказа" страницы Эндрю. По крайней мере, я на это надеюсь.

Новые модификации ядра 2.4.

Давайте начнем с ядра. Я обсуждал стабильную 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 на ядро (это уже сделано).

Предостережение пользователям laptops.

Ext3 имеет твердую репутацию устойчивой файловой системы, и я с удивлением узнал, что у нескольких пользователей лаптопов возникли проблемы при переходе на ext3. Был соблазн, как реакция на подобные сообщения, отказаться от использования ext3. Однако, разбираясь в причинах таких явлений, я обнаружил, что проблемы не связаны непосредственно с ext3, а были вызваны жесткими дисками лаптопов.

Кэш записи

Вы можете этого и не знать, но самые современные жесткие диски имеет нечто, называемое кэшем записи (write cache). Он используется диском для сбора ожидающих обработки операций записи. Помещая ожидающие обработку записи в кэш, встроенное программное обеспечение диска может переупорядочивать и группировать их так, чтобы они были записаны на диск самым быстрым из возможных способов. Кэш записи с такой позиции очень полезная вещь.

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

Ситуация оказалась еще хуже. Некоторые современные laptop hard drives имеют еще более "вредную" привычку без команды сбрасывать свой write cache, когда система перезагружается или "засыпает". Если hard drive наделен обеими features, а файловая система поддерживает журнализацию, происходит периодическое разрушение данных и нельзя ничего предпринять для предотвращения этого.

Где решение? Если вы имеете лаптоп, действуйте осторожно. Сохраните важные файлы перед внесением больших изменений в файловую систему. Если возникнут проблемы с нарушением целостности данных после перехода на ext3, возможно причина в "продвинутости" вашего диска. В таком случае можно войти в контакт с изготовителем диска ваего лаптопа по вопросу о его замене. Есть надежда, что уже в ближайшее время эти диски уйдут с рынка (или переместятся на рынки третьих стран - прим. переводчика) и о проблеме можно будет забыть.

Теперь, после испуга, вы готовы к обсуждению различных ext3 опций journaling данных.

Опции журналирования и производительность

Ext3 предлагает на выбор три режима журналирования при монтировании файловой системы: data=writeback, data=ordered и data=journal.

Для указания режима журналирования можно добавить соответствующую строку (например, data=journal) в поле опций записи в /etc/fstab или непосредственно в командной строке указать -o data=journal при вводе команды mount. Для указания метода журналирования на корневой файловой системе (по умолчанию data=ordered) можно использовать специальнуюопцию загрузки ядра, называемую rootflags. Например, для указания монтирования корневой файловой системы в режим полного журналирования данных, добавьте rootflags=data=journal в строку опций загрузки ядра.

Режим data=writeback

В режиме data=writeback, файловая система ext3 не выполняет какого либо журналирования данных. С подобным видом журналирования вы имеете дело в файловых системах XFS, JFS и ReiserFS (журналирование только метаданных). Как объяснялось впредыдущих статьях, это не защитит от разрушения данные в обновляемых файлах в случае неожиданной перезагрузки. Несмотря на этот недостаток, режим data=writeback обеспечивает самую высокую производительность ext3 при всех условиях.

Режим data=ordered

В режиме data=ordered файловая система ext3 "официально" журналирует только метаданные, но логически метаданные и блоки данных группируются в единый модуль, называемый транзакцией (transaction). Перед записью новых метаданных на диск, связанные блоки данных записываются первыми. Режим data=ordered эффективно (хотя без гарантии) решает проблему c разрушением данных, свойственную режиму data=writeback и большинству других журналируемых файловых систем. Заметьте, делается это без полного журналирования данных. По производительности следует заметить, что data=ordered в ext3 работает несколько медленнее data=writeback, но заметно быстрее полного журналирования данных.

Что касается гарантии от разрушения данных. При добавлении данных в конец файла режим data=ordered гарантированно обеспечивает целостность (как при полном журналировании). Однако если данные в файл пишутся поверх существующих, то есть вероятность перемешивания "оригинальных" блоков с модифицированными. Это результат того, что data=ordered не отслеживает записи, при которых новый блок ложится поверх существующего и не вызывает модификации метаданных. В режиме data=ordered порядок записи отслеживается только до попадания в кэш жесткого диска. Такое ограничение не должно огорчать пользователей, так как операция добавления в конец файла более обычна, чем наложение записи. По этой причине режим data=ordered хорошая альтернатива для режима full data journaling.

Режим data=journal

Режим data=journal обеспечивает полное журналирование и метаданных, и самих данных. Все новые данные сначала пишутся в журнал и только после этого переносятся на свое постоянное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние.

Теоретически, режим data=journal самый медленный из всех режимов журналирования, так как данные записываются на диск два раза. Однако было доказано, что в отдельных случаях режим data=journal показывает неплохие результаты. Эндрю Мортон, после знакомства с отчетами LKML о том, что в ext3 data=journal иногда неожиданно выдает высокую производительность, решил провести небольшое тестирование. Сначала он написал простой сценарий оболочки, предназначенный для записи данных на тестируемую файловую систему с максимально возможной скоростью:

Быстрая запись.

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 (в которой журналирование вообще отсутствует):

Written-to-filesystem 16-meg-read-time (seconds) ext2
78
ReiserFS
67
ext3 data=ordered
93
ext3 data=writeback 74
ext3 data=journal
7

Эндрю повторил тестирование, изменив условия. Чтение 16Mb файла происходило с тестируемой файловой системы. Результат оказался аналогичным. Что из этого следует? Так или иначе, но режим data=journal очень хорошо подходит для случаев, когда данные должны одновременно читаться и записываться. Поэтому режим data=journal, который теоретически считался самым медленным, оказывается, имеет преимущество в среде, сильно нагруженной интерактивными операциями ввода/вывода. По крайней мере, режим data=journal не настолько вял, как казалось бы!

Эндрю еще не нашел объяснений, почему так происходит. Возможно, ответ на этот вопрос поможет в совершенствовании ext3 так, чтобы режимы data=writeback и data=ordered стали более производительными.

data=journal tweaks

Сообщалось о специфической проблеме при использовании ext3 в режиме data=journal на нагруженных серверах и нагруженных NFS серверах в частности. Каждые тридцать секунд сервер испытывает "шторм записей" на диск, прекращая реагировать на все остальное. Если вы столкнулись с такой проблемой, ее можно устранить. Введите следующую команду (с привилегиями root) для "подстегивания" Linux's dirty buffer-flushing algorithm:

Tweaking bdflush

echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush

Такая настройка bdflush заставит kupdate выполняться каждые 0.6 секунд, а не через 5 секунд (по умолчанию). Кроме того, ядру сообщается необходимость сброса на диск содержимого буфера через 3 секунды, а не через 30 (значение по умолчанию). Регулярно и часто сбрасывая на диск недавно измененные данные, можно избежать затяжных "штормов записи". Помните, это снизит эффективность работы (особенно при небольшой загрузке системы), так как у ядра будет меньше возможностей для объединения операций записи. Нагруженному серверу снижение эффективности не грозит, а интерактивность будет улучшена.

Заключение.

Об ext3 хватит. Приглашаю к чтению моей следующей статьи, поскольку речь пойдет о многих чудесах ... XFS!