| Каталог документации / Раздел "Документация для Linux" / Оглавление документа |
| |
|
Daniel Robbins ([email protected])
President/CEO, Gentoo
Technologies, Inc.
November 2001
С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. Daniel Robbins отвечает на эти вопросы по ходу пояснения инсталляции этих новых продвинутых filesystems под Linux 2.4. По большей части статья основана на ext3 - новой улучшенной версии ext2 с возможностями journaling.
В прошлых статьях имелся обзор non-traditional filesystems типа tmpfs и devfs. Теперь пришло время вернуться к disk-based filesystems, и это делается на примере ext3. Ext3 filesystem, разработанная Dr. Stephen Tweedie, сформирована на структурах существующей ext2 filesystem; фактически, ext3 очень похожа на ext2 за исключением маленького (но важного) отличия - она поддерживает journaling. После такого "маленького" добавления в ext3 появились некоторые удивительные и интригующие возможности. В этой статье дается сравнение ext3 с другими journaling filesystems, доступными для использования уже сегодня. Планируется выход еще одной статьи об использовании ext3.
Пояснения к Ext3
Что собой представляет ext3 в сравнении с ReiserFS? В предыдущих
статьях отмечалось, насколько хорошо ReiserFS подходит для работы с маленькими
файлами (до 4КБ), и в отдельных случаях работа с такими файлами в ReiserFS
в десять - пятнадцать раз эффективней, чем в ext2 (и ext3). Однако, кроме
достоинств, ReiserFS имеет и свои слабости. В текущем релизе ReiserFS
(версия 3.6) некоторые виды доступа к файлу фактически приводят к заметному
снижению производительности в сравнении с ext2 и ext3 (особенно при чтении
больших почтовых каталогов). Кроме того, ReiserFS не имеет хорошей
совместимости с NFS и имеет проблемы с производительностью при дефиците
свободного дискового пространства. Напротив, ext3 с этими задачами справляется
великолепно. Она во многом подобна ext2; не ставит рекордов при обработке
маленьких файлов, но хорошо прогнозируемая и не боится работы при ограниченных
дисковых ресурсах.
Еще одно достоинство ext3 происходит из того, что она основана на коде ext2.
Дисковый формат ext2 и ext3 идентичен; из этого следует, что при необходимости
ext3 filesystem можно монтировать как ext2 без каких либо проблем. И это
еще не все. Благодаря факту, что ext2 и ext3 используют идентичные метаданные,
имеется возможность оперативного обновления ext2 в ext3. Именно так.
Имеется ряд системных утилит, работающих с современными 2.4 ядрами (например,
tune2fs) позволяющих конвертировать имеющуюся ext2 в
journaling ext3. Удивительно, но сделать это можно даже на смонтированной
ext2 filesystems. Переход безопасен, обратим и сравнительно легок (в отличие
от конвертирования к XFS, JFS или ReiserFS - какого либо копирования данных
на другой раздел не требуется). Теперь представьте на мгновение тысячи
промышленных ext2 серверов (уже работающих), для которых обновление до ext3
минутное дело; можно получить хорошее представление о перспективности ext3's
в Linux семействе.
Если от меня потребуют дать характеристику ext3 в одном слове, я бы сказал - удобная. Это действительно удобно как следствие насколько только возможной совместимости ext3 с существующей ext2. После обновления вам не придется сталкиваться с любыми неожиданностями. Есть еще одна характеристика, положительно отличающая ext3 от остальных journaled filesystems под Linux - высокая надежность, но об этом ниже.
Надежность Ext3
В дополнение к ext2-compatible, ext3 наследует другие преимущества общего
формата metadata. Пользователи ext3 имеют в своем распоряжении годами
проверенный fsck tool. Конечно, основная причина перехода на journaling
filesystem - отказ от необходимости периодических и долгих проверок
непротиворечивости метаданных на диске. Однако "журналирование" не способно
защитить от сбоев ядра или повреждения поверхности диска (или кое-чего
подобного). В аварийной ситуации вы оцените факт преемственности ext3 от ext2
с ее fsck. Напротив, ReiserFS fsck еще находится в младенчестве и устранение
нарушений в метаданных может стать трудным и опасным процессом.
Metadata-only journaling
Интересно то, что ext3 выполняет journaling совсем иначе, чем ReiserFS и
другие journaling filesystems. В ReiserFS, XFS и JFS filesystem журналируются
метаданные привода и не предусмотрено какое либо журналирование самих
данных. При metadata-only journaling метаданные хранятся
так надежно, что, скорее всего вам не придется пользоваться fsck. Однако,
неожиданные перезагрузки и сбои в электропитании могут приводить к утере
данных, которые в момент сбоя записывались на диск. Ext3 использует
несколько творческих решений для избежания таких проблем.
Сначала поясним ситуацию с metadata-only journaling. Например,
вы редактировали файл /tmp/myfile.txt в момент, когда машина неожиданно
блокировалась. В случае с metadata-only journaling filesystem (например,
ReiserFS, XFS или JFS) ваши filesystem метаданные утрачены не будут и запуска
fsck не потребуется.
Однако, в случае такого сбоя имеется высокая вероятность, что в файле
/tmp/myfile.txt останется один мусор, а то и просто он станет
нечитабельным.
Причина в следующем. "Обычные" journaled filesystems, подобные ReiserFS, XFS и JFS опекают метаданные, но для повышения производительности заботу о данных не проявляют. В нашем примере происходила модификация некоторых filesystem блоков и соответствующих им метаданных, но синхронизация была неожиданно прервана. "Непротиворечивость" файловых блоков будет восстановлена, чего нельзя сказать об их "наполнении".
Журнализация в ext3
Теперь, когда имеется общее понимание проблемы, посмотрим, как ext3
осуществляет journaling. В коде журнализации для ext3 используется специальный
API, называемый Journaling Block Device layer или JBD. JBD был разработан
для журнализации на любых block device. Ext3 привязана к JBD API. При этом код
ext3 filesystem сообщает JBD о необходимости проведения модификации и
запрашивает у JBD разрешение на ее проведение. Журналом управляет JBD от имени
драйвера ext3 filesystem. Такое соглашение очень удобно, так как JBD развивается
как отдельный, универсальный объект и может использоваться в будущем для
журналирования в других filesystems.
Имеется два важных момента в JBD-managed ext3 journal, вытекающих из хранения журнала в inode файле (в базовом варианте). Первое, в зависимости от ключей монтирования ext3 filesystem, этот файл можно "видеть" или "не видеть" (расположен в /.journal). Второе, такое хранение журнала делает возможным переход к ext3 через простое добавление единственного файла (и замену драйвера) без использования несовместимых расширений к ext2 метаданным. Это ключ к пониманию "обратной совместимости" ext3 filesystem с ext2 метаданными и "прямой совместимости" ext2 с ext3 драйвером.
Различные подходы к journaling
Нетрудно догадаться, что имеется несколько способов ведения журнала. Например,
разработчик filesystem может спроектировать журнал, который хранит промежуточные
байты, подлежащие модификации в файловой системе. Преимущество такого подхода в
том, что журнал хранил бы большое число крошечных модификаций очень эффективным
способом, так как требуется запись только отдельных байтов и ничего больше.
JBD использует иной подход. Вместо регистрации промежуточных байтов сохраняются полностью измененные блоки файловой системы. Драйвер Ext3, аналогично, хранит полные точные копии модифицируемых блоков (1КБ, 2КБ или 4КБ) в памяти до завершения операции IO. Это может показаться расточительным. Полные блоки содержат не только изменившиеся данные, но и не модифицированные.
Подход, используемый JBD, называется "физическим журналированием", что отражает использование JBD "физических блоков" как основную единицу ведения журнала. Подход, когда хранятся только изменяемые байты, а не целые блоки, называется "логическим журналированием" (используется XFS). Поскольку ext3 использует "физическое журналирование", журнал в ext3 имеет размер больший, чем в XFS. За счет использования в ext3 полных блоков, как драйвером, так и подсистемой журналирования нет сложностей, которые возникают при "логическом журналировании". Кроме того, использование полных блоков позволяет исполнение некоторой дополнительной оптимизации, например "squishing" нескольких ожидающих обработки операции IO в пределах моноблока в одной структуре оперативной памяти. Это позволяет ext3 записывать на диск несколько смежных модификаций одной операцией. Как дополнение, при операциях записи существенно сокращается нагрузка на CPU.
Защита данных в Ext3
Теперь можно поговорить о том, как ext3 filesystem обеспечивает журнализацию
и data, и metadata. Фактически в ext3 имеются два метода
гарантирования непротиворечивости.
Первоначально ext3 разрабатывалась для журналирования full data и metadata. В этом режиме (называется "data=journal" mode), JBD журналирует все изменения в filesystem, связанные как с data, так и с metadata. При этом JBD может использовать журнал для отката и восстановления metadata и data. Недостаток "полного" журналирования в достаточно низкой производительности и расходе большого объема дискового пространства под журнал.
Недавно для ext3 был добавлен новый режим журналирования, который сочетает высокую производительность и гарантию непротиворечивости структуры файловой системы после сбоя (как у "обычных" журналируемых файловых систем). Новый режим работы обслуживает только metadata. Однако драйвер ext3 filesystem по-прежнему отслеживает обработку целых блоков данных (если они связаны с модификацией метаданных), и группирует их в отдельный объект, называемый transaction. Транзакция будет завершена только после записи на диск всех данных. "Побочный" эффект такой "грубой" методики (называемой "data=ordered" mode) - ext3 обеспечивает более высокую вероятность сохранности данных (по сравнению с "продвинутыми" журналируемыми файловыми системами) при гарантии непротиворечивости metadata. При этом происходит журналирование изменений только структуры файловой системы. Ext3 использует этот режим по умолчанию.
Заключение
В настоящее время многие пытаются определиться, какая из поддержанных в Linux
журналируемых filesystem является "лучшей". По большому счету, все определяется
тем, для каких целей и каких приложений файловую систему планируется
использовать; каждая имеет свои достоинства и недостатки. Безусловное
преимущество пользователей Linux - возможность выбора между файловыми системами
нового поколения. Вместо приклеивания ярлыка "лучшей" файловой системы,
следует понять силу и слабость каждой и принять обоснованное решение.
Ext3 имеет множество преимуществ. Она разработана для максимальной простоты развертывания. Она основана на годами проверенном коде ext2 и получила "по наследству" замечательный fsck tool. Ext3 в первую очередь предназначена для приложений, не имеющих встроенных возможностей по гарантированию сохранности данных. В целом, ext3 - замечательная файловая система и достойное продолжение ext2. В моей следующей статье будет описана установка и работа с ext3. До этого можете посмотреть некоторые ресурсы.
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 Добавить, Поддержать, Вебмастеру |