А зачем разработчики XFS решили использовать allocation groups? В первую очередь это сделано для эффективной параллельной обработки операций ввода/вывода. Поскольку каждая allocation group это эффективно управляемый автономный объект, ядро может распределять нагрузку между несколькими allocation groups. Без allocation groups код файловой системы XFS стал бы "узким горлом" для производительности, вынуждая жадные до ввода/вывода процессы "выстраиваться в цепочку" для модификации inode и выполнения других операций над метаданными. Благодаря allocation groups код XFS допускает многонитевое распараллеливание, а процессы могут работать параллельно, даже при сложных операциях ввода/вывода на одной файловой системе. Если у вас работает XFS, то ограничения по скорости, даже на высококлассном оборудовании, не будут определяться кодом файловой системы. Allocation groups в еще большей степени способствуют оптимизации параллельных операций ввода/вывода на многопроцессорных системах, так как в процессе изменения одновременно могут находиться несколько модификаций метаданных.
Внутренне, allocation groups используют эффективные B+ деревья (B+ trees) для отслеживания важных данных, например, диапазонов [ranges] (еще называются "extents") свободного дискового пространства и, конечно, inodes. Фактически, каждая allocation group имеет три B+ trees, при этом для отслеживания свободного пространства используются два. Одно дерево индексирует экстенты свободного дискового пространства по размеру, а второе - по начальному физическому положению на блочном устройстве. Способность быстро находить подходящие области на свободном пространстве - критическое условие для оптимизации операций записи (то, что положительно отличает XFS от других файловых систем).
В XFS очень эффективно организовано управление инодами. Каждая allocation group ассигнует иноды как ей это удобно в группы по 64. Каждая allocation group хранит свои иноды, используя B+ tree, и каждый конкретный inode number может быть быстро найден на диске. Можно сказать, что XFS использует B+ trees где это только возможно, что и способствует повышению производительности.
Bind mounting делает возможными еще более "тонкие" вещи. Например, вы монтируете tmpfs к /dev/shm, его "традиционной" точке, но одновременно хотите использовать tmpfs для /tmp. Вместо монтирования еще одной tmpfs к /tmp (что возможно), вы решаете share новый /tmp с /dev/shm. Но, bind mount /dev/shm к /tmp нужно сделать так, чтобы каталоги из /dev/shm не были видны в /tmp. Как это сделать? Пример:
В этом примере сначала создается каталог /dev/shm/tmp и назначаются права доступа 1777 (обычные для /tmp). Далее можно монтировать только отдельный /dev/shm/tmp. После этого файл /tmp/foo будет дополнительно виден как /dev/shm/tmp/foo, но файл /dev/shm/bar в каталоге /tmp отображен не будет.
Примечание переводчика. Здесь очень быстро "пролистали" тонкие вещи. chmod 1777 /dev/shm/tmp устанавливает наследование прав в "стиле Беркли" (единичка в аргументах). Если этого не сделать, например, X-сервер после перезагрузки "грохнется на старте". Второй момент - "аномальное" наследование при монтировании. Родительский каталог (точка монтирования /tmp) наследует свойства от дочернего каталога (/dev/shm/tmp). "Не логично", и "по незнанию" может стать причиной проблем.
Как следует из примера, bind mounts очень сильное средство и может помочь в проектировании файловой системы сложной архитектуры.
Используя bind mount, мы можем монтировать всю или только часть уже смонтированной файловой системы к другой точке и иметь файловую систему, доступную от обеих точек монтирования одновременно! Например, можно использовать bind mounts для монтирования корневой файловой системы к /home/drobbins/nifty:
Теперь, если зайти в /home/drobbins/nifty, вы увидите вашу корневую файловую систему (/home/drobbins/nifty/etc, /home/drobbins/nifty/opt и т.д.). Если модифицируется файл на ней, все изменения будут видны и в /home/drobbins/nifty. Так происходит потому, что это одни и те же разделы диска, просто ядро отображает файловую систему в двух разных точках монтирования. Обратите внимание, когда происходит монтирование файловой системы к новой точке через bind-mounted, все файловые системы, которые были примонтированы к "оригинальной", в новой позиции отображены не будут. Другими словами, если /usr создан на отдельном разделе, после выполнения bind-mounted подкаталог /home/drobbins/nifty/usr окажется пустым. Потребуется дополнительное bind mount, чтобы просмотреть содержимое /usr в /home/drobbins/nifty/usr:
За прошедшие несколько месяцев XFS стала самой популярной файловой системой для Linux. Такой вывод следует из обратной связи с пользователями Gentoo Linux. Тенденция выбора в пользу XFS сложилась из-за ее хороших рабочих характеристик. Однако, в релизах 1.0.x XFS страдала одной серьезной проблемой. Давайте повторимся. Файловые системы, журналирующие только метаданные, которыми являются XFS и ReiserFS, допускают нарушение целостности самих данных. Такое происходит когда метаданные о файле модифицируются перед непредвиденным обстоятельством (аварийным отказом). Но, если у ReiserFS попавший под разрушение файл будет содержать старые (а при некоторых обстоятельствах "мусорные") блоки данных, то в случае с XFS блоки заполняются двоичными нулями. Было замечено, что XFS 1.0.x имеет плохую тенденцию обнулять слишком много модифицируемых файлов при зависании сервера или нарушении электропитания. Те, кто использовал XFS на надежном сервере с источником бесперебойного питания, чуствовали себя прекрасно. У тех, кто устанавливал XFS на системе с низкой стабильностью из за программных или аппаратных проблем, возникал большой риск накопления потерянных данных.
К счастью, разработчики SGI XFS существенно снизили такую тенденцию в релизе 1.1 XFS. Проблема проявлялась более заметно в XFS 1.0 по причине того, что слишком многие виды модификаций метаданных требовали журналирования строго в порядке их следования. Такие упорядоченные апдейты метаданных, еще называемые "синхронными" модификациями, оказывают эффект форсированной записи всех предшествующих (отложенных) модификаций. Здесь и возникала проблема. Вынужденно ранняя запись метаданных на диск (а за каждой такой операцией стоят свои блоки с данными) приводил к накапливанию блоков, которые ожидали свою запись на диск еще около 30 секунд после обновления метаданных о них. То есть, создавалось относительно большое окно для возможной утери данных.
|
Техническое примечание.
В релизе 1.1 XFS метаданные файловой системы модифицируются синхронно только в двух случаях:
если файловая система должна ассигновать новое пространство и имеется отложенная транзакция, способная освободить точно такое же пространство
если XFS обрабатывает транзакцию для файлов, открытых с опцией O_SYNC (synchronous). В таком случае запись в файл станет причиной того, чтобы все остальные отложенные операции по изменению метаданных файловой системы будут сброшены на диск
К счастью, подавляющее большинство операций обычного сервера асинхронны по своей природе.
<
/p>
Если система стала перезагружаться или повисла при наличии "окна" (т.е. после того, как информация об изменении метаданных была записана не только в журнал, но и на диск, а соответствующие этой операции блоки данных еще "висят" в памяти), то как старые, так и новые данные окажутся утерянными. Происходит это по следующей причине. Запись метаданных на диск стирает ссылку на первоначальный блок с данными и указывает на блок, в который новые данные пока еще не записаны. Когда сервер запускается после аварийного отказа, код XFS просматривает журнал, распознает ситуацию и заполняет незаписанные блоки двоичными нулями в целях предосторожности. К сожалению, данные затираются навсегда.
Эта проблема особенно неприятна в ситуациях, когда файлы регулярно переписываются "поверх" новыми данными. В таком случае раннее сбрасывание метаданных на диск создает большое окно, что может привести к потере содержимого всего файла при зависании системы в неудачное время. Именно такой сценарий сработал некоторое время назад на сервере gentoo.org. Так как наше mailman mailing list software каждые несколько минут переписывало поверх собственный конфигурационный файл, оно и стало главным кандидатом в жертвы описанному сценарию.
Вывод из ситуации следующий: парни из SGI существенно улучшили ситуацию в релизе 1.1 XFS. Если вы имеете 1.0 XFS, то должны в самое ближайшее время спланировать переход на XFS 1.1. В XFS 1.1 сделано множество и других исправлений. Как только в SGI уменьшили зависимость XFS от синхронных модификаций это оказало положительный эффект на "неудобную" в XFS 1.0.x операцию удаления файлов. Yay!
Что в ближайшей перспективе? Мы можем ожидать выхода нового релиза XFS, который лучше адаптирован под платформу Itanium (Intel). Сейчас XFS для Linux требует, чтобы у XFS размер блока файловой системы точно совпадал с размером страницы оперативной памяти платформы. Становится невозможным просто взять и переставить диск из системы x86 на Itanium, так как в Itanium размер страницы 64 K, а на x86 аппаратно поддержана страница 4 K. Размер файлового блока в 64 K близок к оптимальному значению для многих задач и используется на Itanium системах. Когда проблема жесткой привязки размеров блока и страницы будет решена, это не только облегчит перенос дисков с файловой системой XFS между платформами x86 и ia64, но и даст дополнительные удобства системным администраторам в выборе наиболее оптимального размера блока для решаемых задач.
Что следует ожидать от прочтения этого цикла статей.
Цель этого цикла состоит в том, чтобы дать твердое, практическое введение в новые файловые системы для Linux, такие как ReiserFS, XFS, JFS, GFS, ext3 и другие. Я хочу "вооружить" читателя практичным взглядом на эти вещи и подготовить к осознанному использованию новых файловых систем. Цель так же в том, чтобы помочь Вам (насколько это возможно) избежать многих потенциальных ловушек. Иначе, предлагается осторожный просмотр файловых систем с позиций стабильности, производительности (плюсов и минусов), любых отрицательных воздействий на приложения, анализ комбинаций kernel/patch и т.п. Рассматривайте цикл статей как "insider's guide" для файловых систем нового поколения.
Это то, что следует иметь в виду. Однако, открывая цикл, я несколько отвлекаюсь от поставленной "практической" цели и отвлекаюсь на небольшое "теоретическое" вступление. Далее будут охвачены две темы, очень важные для Linux-сообщества - "журналирование" и "техническая" точка зрения на проект ReiserFS. Журналирование (Journalling) - технология, которую долго ждали, и пришло время ее практического использования. На этой технологии работают ReiserFS, XFS, JFS, ext3 и GFS. Важно точно понять, что собственно делает журналирование, и почему Linux в ней нуждается. Даже если вам это хорошо известно, я надеюсь, что мое введение в журналирование Вам будет полезно. Это хорошая "рыба" для объяснения технологии другим и кое-что для практики. Часто процесс внедрения нового приходится начинать с "Linux guy/gal", убеждая других в необходимости "качественного скачка".
Во второй части статьи рассматриваются технические аспекты ReiserFS. Делается это для демонстрации того факта, что новые файловые системы делают ту же работу, что и "традиционные", но часто немного быстрее. Они также позволяют выполнять работу способами, прежде невозможными. Первая статья важна для понимания всего цикла. Возможности новых файловых систем, вероятно, затронут будущее развитие Linux.
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 (значение по умолчанию). Регулярно и часто сбрасывая на диск недавно измененные данные, можно избежать затяжных "штормов записи". Помните, это снизит эффективность работы (особенно при небольшой загрузке системы), так как у ядра будет меньше возможностей для объединения операций записи. Нагруженному серверу снижение эффективности не грозит, а интерактивность будет улучшена.
Delayed allocation.
Этот краткий технический обзор XFS завершается описанием delayed allocation, еще одной особенности, уникальной среди файловых систем. Определимся с терминами. Понятие allocation относится к процессу обнаружения свободных областей для записи новых данных.
XFS выполняет allocation, разделяя, казалось бы, неделимый процесс на два шага. Сначала, когда XFS получает данные для записи, выполняется запись ждущей транзакции [pending transaction] в RAM и просто резервируется соответствующее количество пространства на основной файловой системе. При этом, резервируя "количество пространства" для новых данных, XFS не решает, какие именно блоки файловой системы эту информацию будут хранить. XFS откладывает принятие окончательного решения до самого последнего момента, когда данные фактически сбрасываются на диск.
Через delaying allocation файловая система XFS получает дополнительные возможности оптимизации скорости. Когда наступает момент фактического сброса данных на диск, XFS может быстро и интеллектуально ассигновать свободное пространство под оптимизацию производительности. В частности, если новые данные добавляются в конец одного файла, XFS может ассигновать смежные области на диске. Если бы XFS не задерживала "до последнего" принятие решения по ассигнованию физических блоков, возможно, данные были бы "размазаны" по множеству несмежных участков. Благодаря задержке "физического" ассигнования, XFS способна делать запись одной операцией, повышая производительность и снижая фрагментацию.
Delayed allocation имеет еще один положительный эффект. Если создается много временных файлов с "маленьким временем жизни", XFS вообще не будет сбрасывать их на диск (ну и что, не только XFS). А теперь внимание, поскольку физические блоки не allocated, отсутствует необходимость в их последующей deallocate. Иначе, не пишутся на диск не только данные, но и не изменяются метаданные файловой системы (а вот это уже кое-то, по сравнению с другими FS).
В общем, ext3 характеризуется как
А что относительно ext3? В общем, ext3 характеризуется как устойчивая и не страдающая серьезными проблемами файловая система. У некоторых она может вызывать "раздражение", поскольку не имеет никаких серьезных усовершенствований по сравнению с ext2, за исключением хорошей реализации журналирования. Подобное "раздражение" в мире файловых систем скорее плюс. Это значит, что файловая система выполняет свои функции без суеты и инцидентов. Кроме того, несмотря на меньшую "продвинутость" ext3 (по отношению к ResierFS, XFS и JFS), она достаточно быстра и имеет хорошие настройки для типичных файловых операций большинства серверов и рабочих станций. Ясно, что разработчики ext3 имели целью создание высококачественной журналируемой системы, на которую Linux пользователи могут смело переходить.
На ядре 2.4.19_pre5 синхронное монтирование ext3 и "chattr +S" файлов стало происходить приблизительно в десять раз быстрее. В самом ближайшем будущем ожидается добавление опции для синхронных модификаций в целых деревьях каталогов, что непременно найдет использование в почтовых программах. Следует ожидать исправлений мелких ошибок и повышения производительности. И ничего мажорного. Код ext3 уже совершенен и находится в эксплуатационном режиме.
Инсталляция инструментария
Теперь, когда вы работаете на ядре, поддерживающем XFS, можно создать и инсталлировать различные XFS tools. Одна из хороших новостей относительно XFS - она поставляется с полным набором инструментов поддержки и утилит. Войдите в каталог linux-2.4-xfs/cmd и запустите (с правами root) следующий сценарий оболочки:
# for x in attr acl xfsprogs dmapi xfsdump do cd $x autoconf /configure --prefix=/usr make make install cd .. done
Не забудьте о переводе строки после done. Наш специальный скрипт начнет работу, и все инструменты XFS будут инсталлированы. После финиша добавим несколько developer-related файлов, которые не инсталлированы предыдущей командой make installl:
# for x in attr dmapi xfsprogs do cd $x make install-dev cd .. done
H4>Создание и монтирование файловой системы.
После отработки скриптов все нужные для XFS программы будут инсталлированы и готовы к использованию. Можно создать тестовую XFS и попытаться достигнуть оптимальной производительности.
Если XFS создается поверх ReiserFS, потребуется небольшая уловка. По приглашению bash введите следующую команду для "обнуления" начального участка блочного устройства, на котором хранилась ReiserFS, а теперь вы собираетесь инициализировать новую файловую систему XFS:
# dd if=/dev/zero of=/dev/hdc9
Такой шаг необходим для eybxnj;tybzt хранящихся ReiserFS метаданных. Иначе, команда mount может "запутаться" и случайно смонтировать новую файловую систему XFS как дефектную ReiserFS! Достаточно позволить dd отработать 10 секунд и прервать комбинацией CTRL-C. При этом все "критические" части ранее существовавшей ReiserFS будут заполнены нулями, а код авто-детектирования типа файловой системы "путаться" больше не будет.
Пришло время создать новую файловую систему. Для этого можно воспользоваться командой mkfs.xfs следующим образом:
# mkfs.xfs /dev/hdc9
Такая команда сделает все необходимое, но имеется пара опций, позволяющих mkfs.xfs сконфигурировать новую XFS под максимальную производительность.
Первая из таких опций -l size=32m, что сообщит mkfs. xfs сконфигурировать файловую систему так, чтобы журнал метаданных имел размер 32 Mb. Это повысит производительность, сделав маловероятным переполнение журнала при высоких нагрузках.
Вторая опция позволяет поднять производительность новой файловой системы, сообщив mkfs.xfs минимизировать число allocation groups. Обычно, mkfs.xfs выбирает число allocation groups автоматически. Но опыт показывает, выбирается число несколько большее, чем требуется для оптимальной производительности однопроцессорных Linuxмашин и серверов. Если вы повторно перечитаете мою предыдущую статью>, allocation groups позволяют XFS выполнять операции над метаданными параллельно. Это очень удобно для high-end серверов, но слишком много allocation groups добавляют работы. Вместо того чтобы разрешить mkfs.xfs автоматически выбрать число allocation groups для вашей файловой системы, сделайте это "вручную", используя -d agcount=x. Выберите x минимальным, например, 4, 6 или 8. Расчет достаточно прост, необходимо иметь, по крайней мере, одну allocation group на каждые 4 GB в целевом блочном устройстве. Две описанные опции позволят создать "оптимизированную" XFS filesystem следующей командой:
# mkfs.xfs -d agcount=4 -l size=32m /dev/hdc9
Теперь, после создания файловой системы, ее можно монтировать. При этом можно воспользоваться некоторыми опциями монтирования, повышающими производительность, чтобы "выжать" максимум из новой файловой системы:
# mount /dev/hdc9 /mnt -o noatime,nodiratime,osyncisdsync
Первые две опции монтирования выключают модификацию atime, что практически никогда и не требуется, но способствует деградации производительности. Опция osyncisdsync добивается такого sync/async поведения XFS, чтобы максимально соответствовать таковому в ext3. Благодаря таким mkfs.xfs и mount ваша новая XFS будет иметь скорость немного выше, чем при умолчании.
Инсталляция tools.
До перезагрузки следует инсталлировать "reiserfsprogs" tools, которые состоят из "mkreiserfs", "resize_reiserfs" (полезно, если у вас используется LVM) и "fsck.reiserfs". Получить самую последнюю версию "reiserfsprogs" (на момент написания статьи - "3.x.0j") можно от . Как только tools загружены, их можно компилировать и инсталлировать следующими командами:
# cd /tmp # tar xzvf reiserfsprogs-3.x.0j.tar.gz # cd reiserfsprogs-3.x.0j # ./configure ./configure output will appear here # make make output will appear here # make install make install output will appear here
После инсталляции инструментария можно создавать новые разделы (используя "fdisk" или "cfdisk") либо LVM logical volumes (используя "lvcreate") по необходимости и перезагрузить систему. Когда создается обычный раздел, его можно маркировать как "Linux native file system" (83).
Использование CVS
Если вы раньше не пользовались CVS, можете воспользоваться моим руководством по CVS для разработчиков и любителей. Даже если вы имеете самое общее представление о CVS, этого будет достаточно. Убедитесь только, что на вашей системе имеется инсталлированный пакет CVS и вам доступна команда cvs.
Описание инструкций CVS, которые будут использоваться далее, можно также найти на сайте SGI. После скачивания исходников через cvs, вы получите новый каталог, содержащий ядро, готовое к использованию XFS, и самые современные инструменты для работы с этой файловой системой. Для скачивания исходников от XFS CVS сначала установите переменную окружения CVSROOT в требуемое значение. Например, в командной строке bash введите:
$ export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
Теперь перейдите в каталог, где вы желаете разместить каталог дерева XFS, и выполните:
$ cvs login
По запросу пароля введите cvs. Теперь вы подключились к общедоступному репозиторию CVS. Получите самые последние исходники XFS, введя:
$ cvs -z3 checkout linux-2.4-xfs
Запустится процесс checkout. Это займет некоторое время, так как файлы, которые вы скачиваете, включают полное дерево исходников ядра Linux. Через некоторое время, когда команда cvs checkout завершится, вы будете иметь новое дерево исходников в текущем рабочем каталоге. Рекомендация на будущее: если вам потребуется модернизировать дерево исходников, просто внутри образовавшегося каталога введите:
$ cvs -z3q update -dP
Использование tmpfs.
Все, что требуется для использования tmpfs - это ядро 2.4, скомпилированное с поддержкой "Virtual memory file system support (former shm fs)" enabled; эта опция находится в подразделе "File systems" (make menuconfig). Если на вашей системе такое ядро, уже можно монтировать tmpfs filesystems. На предкомпилированных ядрах дистрибутивов это, как правило, сделано всегда. Можно не пользоваться самой tmpfs, но такая поддержка требуется для использования POSIX shared memory. Заметим, для использования System V shared memory поддержка tmpfs в ядре не требуется. POSIX shared memory широкого применения еще не получила, но это дело времени.
Это не блочное устройство.
Теперь о другом интересном свойстве tmpfs. В отличие от большинства "нормальных" файловых систем (например, ext3, ext2, XFS, JFS, ReiserFS) tmpfs не является "надстройкой" над блочным устройством. Поскольку tmpfs напрямую "встроена" в VM, ее можно монтировать сразу после создания командой:
# mount tmpfs /mnt/tmpfs -t tmpfs
После выполнения команды вы получите новую файловую систему tmpfs, смонтированную в /mnt/tmpfs и готовую к использованию. Обратите внимание, нет потребности в форматировании командой mkfs tmpfs; да это и невозможно, такой команды просто не существует. Сразу после команды mount файловая система доступна для использования и имеет тип tmpfs. Это в принципе отличается от Linux ramdisks; стандартный Linux ramdisks - block devices и требует форматирования перед размещением на нем файлов. Что имеем? Монтируй и используй!
Кэш записи
Вы можете этого и не знать, но самые современные жесткие диски имеет нечто, называемое кэшем записи (write cache). Он используется диском для сбора ожидающих обработки операций записи. Помещая ожидающие обработку записи в кэш, встроенное программное обеспечение диска может переупорядочивать и группировать их так, чтобы они были записаны на диск самым быстрым из возможных способов. Кэш записи с такой позиции очень полезная вещь.
К сожалению, некоторые диски лаптопов имеют сомнительную возможность игнорирования любого "официального" ATA-запросаt с требованием сброса на диск их кэша. Возразить нечего, такая "замечательная" особенность до недавнего времени не была запрещена ATA спецификацией. При взаимодействии с такими типами дисков у ядра нет возможности гарантировать, что специфический блок был "фактически" сброшен на диск. Хотя это необходимая причина вдруг возникшей проблемы с нарушением целостности данных, но еще не достаточная.
Ситуация оказалась еще хуже. Некоторые современные laptop hard drives имеют еще более "вредную" привычку без команды сбрасывать свой write cache, когда система перезагружается или "засыпает". Если hard drive наделен обеими features, а файловая система поддерживает журнализацию, происходит периодическое разрушение данных и нельзя ничего предпринять для предотвращения этого.
Где решение? Если вы имеете лаптоп, действуйте осторожно. Сохраните важные файлы перед внесением больших изменений в файловую систему. Если возникнут проблемы с нарушением целостности данных после перехода на ext3, возможно причина в "продвинутости" вашего диска. В таком случае можно войти в контакт с изготовителем диска ваего лаптопа по вопросу о его замене. Есть надежда, что уже в ближайшее время эти диски уйдут с рынка (или переместятся на рынки третьих стран - прим. переводчика) и о проблеме можно будет забыть.
Теперь, после испуга, вы готовы к обсуждению различных ext3 опций journaling данных.
Монтирование поверх занятой точки монтирования
При использовании ядер 2.2 любая попытка монтирования к уже используемой точке монтирования приводила к ошибке. После переписи кода ядра повторное монтирование к занятой точке перестало быть проблемой. Такой пример: при загрузке системы монтируется "реальный" раздел диска к точке /tmp. Принимается оперативное решение использовать tmpfs. В старое время потребовалось бы размонтировать /tmp и повторно смонтировать tmpfs в /tmp:
# umount /tmp # mount tmpfs /tmp -t tmpfs -o size=64m
Однако не всегда это возможно. Если есть процессы с открытыми в /tmp файлами будет выдана следующая ошибка:
umount: /tmp: device is busy
На последних 2.4 ядрах можно перемонтировать /tmp filesystem без получения ошибки "device is busy":
# mount tmpfs /tmp -t tmpfs -o size=64m
Единственной командой ваша новая файловая система tmpfs монтируется к /tmp поверх ранее смонтированного раздела. При этом все новые файлы будут открываться на tmpfs, а процессы, которые имели открытые файлы на "оригинальной" файловой системе, так и будут продолжать работать с ними! Если размонтировать tmpfs-based /tmp, "оригинальная" /tmp появится, как и прежде. Фактически, можно монтировать любое число файловых систем на одну точку монтирования, и точка монтирования будет действовать подобно стеку.
ext3 наследует другие преимущества общего
В дополнение к ext2-compatible, ext3 наследует другие преимущества общего формата метаданных. Пользователи ext3 имеют в своем распоряжении годами проверенный инструментарий fsck. Конечно, основная причина перехода на журналируемую файловую систему - отказ от необходимости периодических и долгих проверок непротиворечивости метаданных на диске. Однако "журналирование" не способно защитить от сбоев ядра или повреждения поверхности диска (или кое-чего подобного). В аварийной ситуации вы оцените факт преемственности ext3 от ext2 с ее fsck. Напротив, ReiserFS fsck еще находится в младенчестве и устранение нарушений в метаданных может стать трудным и опасным процессом.
Немного больше о notail.
Не следует думать, что упаковка хвостов больших файлов имеет одни достоинства. Один из недостатков - снижение производительности. Разработчики ReiserFS предполагали, что ряд пользователей решит не жертвовать производительностью ради 5% экономии дискового пространства. Была предусмотрена опция монтирования "notail". Когда файловая система монтируется с этой опцией, упаковка хвостов отключается, что дает прирост скорости при меньшей вместимости диска. С учетом сегодняшней стоимости дискового пространства следует рекомендовать монтирование файловой системы с опциями "notail" и "noatime":
/dev/hdc1 /home reiserfs noatime,notail 0 0
Даже если имеется потребность в экономии дискового пространства, может оказаться хорошей идеей временное монтирование файловой системы (пока не заполнилась) с опцией "notail". Кроме того, некоторые загрузчики имеют проблемы с загрузкой ядер, созданных на ReiserFS с tail packing enabled. Если у вас LILO старее версии 21.6, с такой проблемой вы обязательно столкнетесь. Могут быть проблемы даже с современными версиями GRUB при загрузке файлов stage1 и stage1_5, хотя на загрузку самого ядра это не влияет. Устранить проблему поможет временное монтирование ReiserFS с опцией "notail" и перемещение файлов в буферную файловую систему "туда обратно". Помните, после пересоздания файлов (инсталляция нового ядра) они снова окажутся "без хвостов". Есть возможность перемонтирования файловой системы (с новыми опциями) без ее размонтирования. Ниже показано, как перемонтировать корневую файловую систему с опцией "notail". Команда будет полезной, если для вас обычная практика - упаковка хвостов, но загрузчик "этого не любит" и требуется "распаковать" вспомогательные файлы:
# mount / -o remount,notail
Новые модификации ядра 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 (смотри дальше), имейте в виду, начиная с 2.4.16 нет надобности накладывать patch на ядро (это уже сделано).
Ограничения ReiserFS.
Хотя ReiserFS превосходит по быстродействию практически во всех типах приложений "файловую классику" ext2, имеется ряд областей, где ReiserFS в настоящее время еще не доработан. Это не жесткие ограничения ReiserFS, а те области, до которых разработчики Namesys не имели время добраться.
Опции журналирования и производительность
Ext3 предлагает на выбор три режима журналирования при монтировании файловой системы: data=writeback, data=ordered и data=journal.
Для указания режима журналирования можно добавить соответствующую строку (например, data=journal) в поле опций записи в /etc/fstab или непосредственно в командной строке указать -o data=journal при вводе команды mount. Для указания метода журналирования на корневой файловой системе (по умолчанию data=ordered) можно использовать специальнуюопцию загрузки ядра, называемую rootflags. Например, для указания монтирования корневой файловой системы в режим полного журналирования данных, добавьте rootflags=data=journal в строку опций загрузки ядра.
Отсутствие dump/restore
Да, это истина. ReiserFS не имеет "dump" и "restore" реализации. Если вы желаете использовать ReiserFS, но вам нравится "dump", придется находить иные пути бэкапу данных. В действительности это не так актуально. Ядро 2.4 несовместимо с "dump" и "restore" в принципе (а не только на ReiserFS). Для подробной информации о dump/kernel 2.4 incompatibility читайте Linus Torvalds, где он говорит, "Dump была глупой программой, во-первых. Оставьте ее в прошлом."
Подготавливаем ядро.
OK, возможны три варианта получения готовой к использованию ReiserFS. Первый, использование простого ядра 2.4.4. Второй, использование ядра 2.4.4 с наложением специального набора патчей для ReiserFS (bigpatch). Третий, использование 2.4.4 ядра с патчами от Алана Кокса, как с bigpatch, так и без него. Далее описывается процесс последний процесс, но если у вас одна или обе patches не установлены, просто пропустите соответствующий шаг. Теперь начнем.
Получите от kernel.org и положите в /usr/src каталог. Переименуйте существовавший linux каталог или symlink на него, либо просто удалите старую symlink. Далее:
# cd /usr/src # cat /path/to/linx-2.4.4.tar.bz2 | bzip2 -d | tar xvf -
Поиск подходящего ядра.
Чтобы сделать доступной ReiserFS на вашей системе, сначала потребуется найти подходящее ядро. Если вы следите за развитием ядер серии 2.4, то, наверное, знаете, что не все происходит гладко. При написании статьи последним было 2.4.6-pre2. Однако я рекомендую обратить внимание либо на 2.4.4 (a stock Linus kernel), либо на 2.4.4-ac9 (модифицированное ядро от Алана Кокса) для установки ReiserFS. Тесты показали, что на 2.4.5 имеются "моменты", которые не позволяют рекомендовать это ядро для промышленного использования. Давайте надеяться, что 2.4.6 в этом плане будет лучше.
Если не хотите использовать 2.4.4 или 2.4.4-ac9 ядро для ReiserFS, прежде убедитесь, что проведены достаточные тесты по исследованию устойчивости ReiserFS на выбранном ядре. Конечно, предупреждение не распространяется для ReiserFS на тестовом сервере, где можно использовать любое ядро, если не поступало сообщений о его "проблемности".
Имеются два серьезных основания для повышенного внимания к проблемам стабильности ядра вообще и стабильности ReiserFS в частности. Первое состоит в том, до сих пор ReiserFS - "экспериментальная" особенность ядра, и вы не должны прогнозировать, что ее реализация на более новом ядре будет работать не хуже, чем на предыдущем. Второе (в данный момент это самая большая проблема), большая часть релизов ядра 2.4 и патчей были немного flaky side, что предполагает большую осторожность. Теоретически, все 2.4 релизы принадлежат стабильной серии, так как 2.4 "по определению" считается таковой. На практике в этом возникают сомнения.
Я надеюсь, что не отговорил вас от использования ReiserFS или Linux 2.4, но предупреждение не будет лишним. Не прыгайте с одного ядра на другое только по причине его "современности". На промышленных системах такая практика ничего хорошего не сулит. Когда переходите на непроверенное ядро, вы рискуете не только зависанием системы, но и сохранностью данных. Даже если сама ReiserFS устойчива, есть вероятность, что ошибки в других частях ядра приведут к повреждению информации на файловой системе.
Если вы еще не выбрали хороший источник информации по стабильности современных ядер, я рекомендую посетить Linux Weekly News, чтобы быть "в курсе" проблем разработки ядра (информация обновляется каждый четверг). Теперь, когда я убедил читателей в использовании 2.4.4 или 2.4.4-ac9 для ответственных инсталляций ReiserFS, продолжим.
В предыдущих статьях отмечалось, насколько
Что собой представляет ext3 в сравнении с ReiserFS? В предыдущих статьях отмечалось, насколько хорошо ReiserFS подходит для работы с маленькими файлами (до 4КБ), и в отдельных случаях работа с такими файлами в ReiserFS в десять - пятнадцать раз эффективней, чем в ext2 (и ext3). Однако, кроме достоинств, ReiserFS имеет и свои слабости. В текущем релизе ReiserFS (версия 3.6) некоторые виды доступа к файлу фактически приводят к заметному снижению производительности в сравнении с ext2 и ext3 (особенно при чтении больших почтовых каталогов). Кроме того, ReiserFS не имеет хорошей совместимости с NFS и имеет проблемы с производительностью при дефиците свободного дискового пространства. Напротив, ext3 с этими задачами справляется великолепно. Она во многом подобна ext2; не ставит рекордов при обработке маленьких файлов, но хорошо прогнозируемая и не боится работы при ограниченных дисковых ресурсах.
Еще одно достоинство ext3 происходит из того, что она основана на коде ext2. Дисковый формат ext2 и ext3 идентичен; из этого следует, что при необходимости файловую систему ext3 можно монтировать как ext2 без каких либо проблем. И это еще не все. Благодаря факту, что ext2 и ext3 используют идентичные метаданные, имеется возможность оперативного обновления ext2 в ext3. Именно так. Имеется ряд системных утилит, работающих с современными ядрами (например, tune2fs) позволяющих конвертировать имеющуюся ext2 в журналируемую ext3. Удивительно, но сделать это можно даже на смонтированной файловой системе ext2. Переход безопасен, обратим и сравнительно легок (в отличие от конвертирования в XFS, JFS или ReiserFS - какого либо копирования данных на другой раздел не требуется). Теперь представьте на мгновение тысячи промышленных серверов с ext2 (уже работающих), для которых обновление до ext3 минутное дело; можно получить хорошее представление о перспективности ext3 в Linux семействе.
Если от меня потребуют дать характеристику ext3 в одном слове, я бы сказал - удобная. Это действительно удобно как следствие насколько только возможной совместимости ext3 с существующей ext2. После обновления вам не придется сталкиваться с любыми неожиданностями. Есть еще одна характеристика, положительно отличающая ext3 от остальных журналируемых файловых систем под Linux - высокая надежность, но об этом ниже.
Положительные герои.
Одна из хороших вещей в XFS - она имеет много специальных функциональных возможностей. Одной из них являются "access control lists" или ACL. Сейчас это поддерживается в XFS по умолчанию. Списки контроля доступа позволяют определять более дробные разрешения на файлы. Например, вместо ограниченного "rwx" для владельца, группы и других, становится возможным добавлять любое число дополнительных пользователей или групп и определять "rwx" permissions и для них.
Полное описание access control lists - вне контекста этой статьи. Если вам это интересно, посмотрите большое введение в ACL на bestbits site, особенно, если посетить страничку "Why you may want Access Control Lists (ACLs)". Обратите внимание, большая часть технической информации этого сайта связана с поддержкой ACL под ext2 и ext3 (но ничего дополнительного не требуется для ACL под XFS).
XFS имеет еще одну особенность, называемую расширенными атрибутами (extended attributes). Такие extended attributes позволяют вам ассоциировать определенные пользователем данные с объектами файловой системы. Например, если вы имеете графический файл по имени mygraphic.png, можно прикрепить к нему атрибут, называемый "thumbnail", содержащий маленькую версию изображения. Эти данные не будут видимы обычными файловыми операциями ввода/вывода, но к ним можно обращаться из программ, использующих API специальных расширенных атрибутов. По своей сути, расширенные атрибуты похожи на ветви ресурсов (resource fork), существующие на MacOS системах.
Имеется пример использования расширенных атрибутов через команду attr из командной строки. Скажем, я желаю добавить атрибут description к моему домашнему каталогу. Я ввожу:
$ attr -s description -V "Home of Daniel Robbins" /home/drobbins Attribute "description" set to a 22 byte value for /home/drobbins: Home of Daniel Robbins
После этого, чтобы видеть список атрибутов, ассоциированных с /home/drobbins, можно ввести:
$ attr -l /home/drobbins Attribute "description" has a 22 byte value for /home/drobbins/
А чтобы просмотреть содержание атрибута description, я ввожу:
$ attr -q -g description /home/drobbins/ Home of Daniel Robbins
Расширенные атрибуты просты и забавны в использовании. Вы можете узнать о них больше, прочитав man attr. XFS включает также API C для взаимодействия с extended attributes. Если вы интересуетесь работой с C++ IOStream интерфейсом к расширенным атрибутам, можете посмотреть libferris на SourceForge.
Конечно, расширенные атрибутыs и ACL открывают интересные возможности, но будьте осторожны. Большинство программ резервного копирования в настоящее время еще "не понимают" ни EA, ни ACL. Известные мне исключения - xfsdump и xfsrestore, поставляемые с XFS distribution. Если используете другую backup программу, проведите сначала интенсивное тестирование на поддержку EA и ACL.
Я надеюсь, вам понравилось это "мгновенное" введение в файловую систему XFS. Ждите новых статей!
Предостережение пользователям laptops.
Ext3 имеет твердую репутацию устойчивой файловой системы, и я с удивлением узнал, что у нескольких пользователей лаптопов возникли проблемы при переходе на ext3. Был соблазн, как реакция на подобные сообщения, отказаться от использования ext3. Однако, разбираясь в причинах таких явлений, я обнаружил, что проблемы не связаны непосредственно с ext3, а были вызваны жесткими дисками лаптопов.
Преимущества tmpfs
Динамически изменяемый размер файловой системы.
Вы вероятно уже задавались вопросом, а какого размера файловую систему мы подмонтировали к /mnt/tmpfs в примере выше? Ответ неожиданный (особенно, если имели дело только с disk-based файловыми системами). /mnt/tmpfs первоначально имеет очень маленький размер, но, по мере копирования и создания файлов драйвер tmpfs ассигнует у VM дополнительную память, динамически увеличивая емкость. Справедливо и обратное, при удалении файлов из /mnt/tmpfs драйвер отдает освобождаемую память операционной системе. Теперь ясно (память достаточно ценный ресурс и ее "никогда не бывает много"), большой плюс tmpfs в том, что используется ровно столько памяти, сколько требуется.
Скорость.
Другое преимущество tmpfs - ее "блестящая" скорость. Поскольку файловая система tmpfs постоянно загружена в оперативную память, операции записи - чтения происходят почти мгновенно. Даже если интенсивно используется swap, скорость все равно высокая (более того, перемещение в swap означает передачу ресурсов процессам, наиболее нуждающимся в памяти, что способствует повышению общей производительности). Итог - свойство динамически изменять размер и, при необходимости, сбрасываться в swap, дает возможность операционной системе более гибко распоряжаться ресурсами. Файловая система tmpfs прекрасная альтернатива традиционному RAM disk с позиции скорости.
Безинерционность.
А вот это может считаться как плюсом, так и минусом. Как можно догадаться, данные в tmpfs после перезагрузки будут потеряны (оперативная память энергозависима по своей природе. Даже после "горячей перезагрузки", сохранившись в "физической оперативной памяти", информация станет недоступной, так как таблицы виртуальной памяти будут инициализированы иначе). Название "tmpfs" само за себя говорит. Плохо ли это? С какой стороны посмотреть. Фактически, tmpfs превосходный резервуар для хранения временных файлов. Традиционно для этих целей используется /tmp и некоторые части дерева /var. Есть даже опция - очищать /tmp при перезагрузке, на что тратится дополнительное время. В случае с tmpfs, такая "опция" - физическое свойство.
Презентация allocation groups.
При создании файловой системы XFS основное блочное устройство разбивается на восемь или больше равных по размеру линейных областей. Их можно было бы назвать "chunks" или "linear ranges", но в терминологии XFS они именуются "allocation group" (что можно на русский язык можно перевести как группы выделения, или группы размещения, однако оригинальное название более понятно - А.Ф.). Уникальность allocation group в том, что каждая группа управляет своими собственными информационными узлами (inodes) и свободным пространством, что превращает группы в своего рода автономные файловые подсистемы, сосуществующие в рамках общей XFS.
Презентация tmpfs.
Если от меня потребуют объяснить в одной фразе, что такое tmpfs, я бы сказал - tmpfs подобие ramdisk, но с "изюминкой". Подобно ramdisk, tmpfs использует ОПЕРАТИВНУЮ ПАМЯТЬ, но, кроме этого, может использовать пространство для своппинга. В то время как традиционный ramdisk это блочное устройство и перед его использованием необходимо отформатировать раздел командой mkfs с опциями, то файловая система tmpfs - устройство не блочное, готовое к использованию сразу после монтирования. Такие свойства tmpfs делают ее самой привлекательной из RAM-based файловых систем, известных на сегодняшний день.
Презентация XFS
Файловая система XFS первоначально была разработана Silicon Graphics, Inc. в начале 90-х годов. В то время в SGI пришли к выводу, что их "базовая" файловая система (EFS) по скорости перестала соответствовать современным требованиям. Изучив проблему, в SGI пришли к выводу, что лучше "с нуля" спроектировать новую высокопроизводительную 64-bit файловую систему, чем попытаться модернизировать EFS. Рождение XFS произошло в релизе IRIX 5.3 в 1994. С этого времени именно эта файловая система становится базовой для всех машин SGI с ОС IRIX от рабочих станций до суперкомпьютеров. Совсем недавно XFS стала доступна и для Linux. Появление поддержки XFS в Linux событие значимое. Теперь Linux обладает устойчивой, современной файловой системой с богатым набором функций, масштабируемой и удовлетворяющей самым высоким требованиям к хранилищам данных.
Приемы повышения производительности
К счастью, имеется пара простых приемов, которые вы можете использовать для "купирования" проблем производительности. Первый прием - монтирование ReiserFS с опцией "noatime" (опция монтирования, доступная и для других файловых систем). Вероятно, вы знаете, что системы UNIX делают запись atime (время доступа) для каждого объекта файловой системы и этот атрибут модифицируется при каждом чтении файла. Для большинства случаев штамп atime интереса не представляет (даже не могу привести пример, когда atime требуется для "критических" приложений). По этой причине, ничем не рискуя, от его модификации можно отказаться и получить выигрыш в производительности. Можно даже сказать следующее. Если вам не известно, что штамп atime требуется для конкретного приложения, разместившего файлы на конкретной файловой системе, то вы должны монтировать ее с опцией noatime. Используйте примерно следующую запись в /etc/fstab:
/dev/hdc1 /home reiserfs noatime 0 0
В я упомянул, что ReiserFS имеет специфическую feature, называемую "tail packing" (упаковка хвостов). А что в ReiserFS называют "хвостами"? Во-первых, файлы, размер которых меньше, чем блок файловой системы или, во-вторых, "кончики" файлов, которые не заполняют весь блок. В первом случае ReiserFS имеет превосходную производительность по причине умения "запихивать" такие "карликовые" файлы в свои b*tree (первичная организационная структура данных). При этом данные хранятся рядом со stat-data (ReiserFS эквивалент i-node). Во втором случае с производительностью иначе. Хвосты не заполняют полный блок и непроизводительно используют дисковое пространство. Для лучшего использования дискового пространства ReiserFS использует "tail packing". Считается, что такая feature позволяет экономить более 5% в сравнении с ext2.
Проблемы производительности.
Хотя ReiserFS в общем, имеет преимущество в производительности над ext2, в частностях имеются и слабости. Первая - работа с "разреженными" файлами (например, mailbox). ReiserFS заметно хуже справляется с разреженными файлами, чем ext2. Положение должно изменится, когда разработчики Namesys вернуться к оптимизации этой стороны ReiserFS (предполагается в версии 4 ReiserFS). А сейчас ext2 - лучшее решение для приложений, которые помещают информацию в разреженные файлы.
Вы можете столкнуться с проблемами при написании кода, который делает связанный вызов stat() для большого числа файлов. Одно из приложений, которое имеет проблемы (проявляется только с ReiserFS на ядрах 2.4, но не с 2.2) - mutt mailer когда он читает большие maildir-style mailboxes. Очевидно, mutt выполняет вызов stats для каждого почтового файла дважды. Это имеет тенденцию замедления работы. В команде разработчиков ReiserFS об этой специфической проблеме знают и работают над ее устранением (решение будет включено в ReiserFS 4 или раньше).
Проблемы с fsck
Нельзя сказать, что описанное - плохой подход к обеспечению целостности файловой системы, но решение не оптимально. Не оптимальность результат того, что fsck должен просканировать все метаданные файловой системы для вывода об их непротиворечивости. Выполнение полной проверки всех метаданных задача сама по себе трудоемкая. К этому следует добавить, что с увеличением размера файловой системы затраты на полное сканирование растут прогрессивно (на персональной машине это может занять несколько минут, на сервере полчаса и больше). И еще, стандартное поведение fsck предполагает периодически проверки после некоторого числа "чистых размонтирований", что не может считаться приемлемым для mission-critical datacenter, когда "время - деньги". К счастью, имеется лучшее решение.
Проект XFS.
В документе представленном в USENIX '96, инженеры SGI поясняют, что XFS была разработана под девизом "думайте о большем". И действительно, XFS снимает некоторые ограничения, присущие традиционным файловым системам. Остановимся на некоторых интригующих особенностях проекта XFS.
Работа с деревом
В начале этого раздела Дэниел рассказывает о подготовке дерева исходников ядра. Эта часть опущена, как полностью утратившая актуальность - А.Ф.
Теперь о конфигурировании ядра. Для поддержки XFS, после make menuconfig перейдите в секцию File systems. Там вы увидите следующую опцию:
< > SGI XFS filesystem support
Разрешите ее (рекомендуется статически компилировать в ядро). Введите "y" и появятся еще три под опции:
[ ] Enable XFS Realtime support [ ] Enable XFS Quota < > Enable XFS DMAPI
Опция "XFS Realtime" разрешает поддержку realtime subvolume в XFS, что позволит в дальнейшем конфигурировать области памяти, обеспечивающие определенную производительность для приложений реального времени. Опция "XFS Quota" позволит, как нетрудно догадаться, поддержку лимитов на размер доступного дискового пространства для пользователей и групп. Опция "XFS DMAPI", если помечена, разрешит специальный API, предназначенный для управления приложениями. В настоящее время под Linux еще нет инструментов, которые пользуются преимуществами DMAPI (имеются у Sistina's LVM и "родные" утилиты SGI XFS). Однако некоторые DMAPI-приложения для Linux уже находятся в разработке у SGI и IBM.
После выбора "SGI XFS filesystem support" и конфигурирования остальной части ядра по вашему вкусу, вы готовы ввести make dep && make && make bzImage && make modules && make modules_install, инсталлировать новое ядро и перезагрузиться. .
Работа с маленькими файлами
Как обстоят дела с размещением в файловой системе большого числа маленьких порций информации? В Namesys решили, по крайней мере, для начала, сосредоточится на одном из аспектов работы файловой системы - работе с маленькими файлами. Строго говоря, файловые системы наподобие ext2 и ufs в этой области ведут себя неэффективно, часто вынуждая разработчиков проектировать базы данных или использовать другие "фокусы" для получения удовлетворительной производительности. Такой подход приводит к "изобретению множества велосипедов" и порождает огромное число несовместимых API узкоспециального назначения.
Разберемся, а за счет чего ext2 поощряет этот вид "велосипедного" программирования. Ext2 хороша для хранения достаточно большого числа файлов размером более двадцати килобайт каждый, но совсем не идеальна для хранения 2,000 50-байтовых файлов. Мало того, что заметно снижается производительность, но и само хранение маленьких файлов на ext2 приводит к неэффективному использованию дискового пространства, так как ext2 ассигнует под каждый файл целое число 1-2-4 KB блоков (размер блока устанавливается при формировании файловой системы).
Обычная житейская мудрость подсказывает нам отказаться от хранения многих смехотворно маленьких файлов непосредственно на файловой системе. Вместо этого возникает идея хранения информации в некоторой базе данных, работающей над файловой системой. В ответ на это Ханс Райзер (Hans Reiser) сказал бы, что всякий раз, когда формируется уровень над файловой системой, это свидетельствует лишь о том, что файловая система не отвечает нашим потребностям. Если бы она удовлетворяла, от этого можно было бы отказаться. Следовательно, хорошо спроектированная файловая система экономит время на разработку и устраняет ни с чем более не совместимый код.
Но это все теория. А как на практике ReiserFS работает с большим числом маленьких файлов? Удивительно, но очень хорошо. Фактически, ReiserFS при обработке файлов размером меньше одного K выигрывает в скорости у ext2 в восемь - пятнадцать раз! Вообще, ReiserFS превосходит по быстродействию ext2 в почти каждой области, но действительно сияет, когда сравнивается обработка маленьких файлов.
Различные подходы к journaling
Нетрудно догадаться, что имеется несколько способов ведения журнала. Например, разработчик файловой системы может спроектировать журнал, который хранит промежуточные байты, подлежащие модификации в файловой системе. Преимущество такого подхода в том, что журнал хранил бы большое число крошечных модификаций очень эффективным способом, так как требуется запись только отдельных байтов и ничего больше.
JBD использует иной подход. Вместо регистрации промежуточных байтов сохраняются полностью измененные блоки файловой системы. Драйвер Ext3, аналогично, хранит полные точные копии модифицируемых блоков (1КБ, 2КБ или 4КБ) в памяти до завершения операции ввода/вывода. Это может показаться расточительным. Полные блоки содержат не только изменившиеся данные, но и не модифицированные.
Подход, используемый JBD, называется "физическим журналированием", что отражает использование JBD "физических блоков" как основную единицу ведения журнала. Подход, когда хранятся только изменяемые байты, а не целые блоки, называется "логическим журналированием" (используется XFS). Поскольку ext3 использует "физическое журналирование", журнал в ext3 имеет размер больший, чем в XFS. За счет использования в ext3 полных блоков, как драйвером, так и подсистемой журналирования нет сложностей, которые возникают при "логическом журналировании". Кроме того, использование полных блоков позволяет исполнение некоторой дополнительной оптимизации, например объединение нескольких ожидающих обработки операции ввода/вывода в пределах моноблока в одной структуре оперативной памяти. Это позволяет ext3 записывать на диск несколько смежных модификаций одной операцией. Как дополнение, при операциях записи существенно сокращается нагрузка на CPU.
ReiserFS
Теперь перейдем к ReiserFS, первой из нескольких журналируемых файловых систем, которые планируется исследовать. ReiserFS 3.6.x (версия для Linux 2.4) разработана Hans Reiser и его командой Namesys. Hans и его команда проповедуют философию, что лучшая файловая система та, которая формирует единую общедоступную среду, или namespace. В такой среде приложения могут взаимодействовать более гибко, эффективно и мощно. Для достижения этого, файловая система должна выполнять часть работы, традиционно выполнявшуюся приложениями. При таком подходе пользователи часто могут продолжать прямое использование файловой системы вместо формирования уровней специального назначения, типа баз данных и т.п.
Очень похоже, что ReiserFS и ядро 2.4 "разрулили" свои противоречия. Лично для меня это хорошая новость. Имею желание вновь начать использовать ReiserFS в качестве корневой файловой системы, как только придет время переустановки моей станции разработчика. Я уверен, что имеются много других экс-ReiserFS-пользователей, которые вернутся обратно, так как пришло спокойствие на "ядерную землю". И в самом деле, трудна жизнь без ReiserFS когда уже знаешь, как благоприятно влияет на некоторые приложения увеличение производительности на маленьких файлах.
А что мы можем ожидать от ReiserFS в ближайшем будущем? Согласно Хансу Рейзеру (Hans Reiser) и его команды, на очереди некоторые очень хорошие усовершенствования. Следует выделить журналирование данных от Криса Мэйсона (Chris Mason) (аналог режима "data=journal" в ext3) и новый код ассигнования блоков, который лучше масштабируется и немного повышает производительность на большых файлах (до 15 % на операциях чтения с IDE дисков). Кроме этих ближайших и существенных изменений мы, вероятно увидим, что ReiserFS поддерживает эквивалент режима "data=ordered" из ext3. То есть, ReiserFS предлагает эквивалент режима data integrity, реализованного в файловой системе ext3. Я очень счастлив видить, что команда разработчиков ReiserFS придает такой высокий приоритет проблеме целостности данных (а не только метаданных).
Решение для Low VM
К счастью, tmpfs позволяет указать максимальный размер файловой системы при ее монтировании или перемонтировании. Фактически, с ядром 2.4.6 и util-linux-2.11g, такие параметры можно установить только при монтировании, но не перемонтировании (в следующих версиях ядер это может быть уже решено). Установка оптимального лимита на размер tmpfs зависит от ресурсов и режима
использования Linux box; идея в том, чтобы предотвратить возможность со стороны tmpfs filesystem истощения ресурсов виртуальной памяти и предотвратить low-VM conditions, о чем говорилось ранее. Хороший способ найти приемлемый tmpfs upper-bound состоит в использовании top монитора для наблюдения за swap в момент пиковых нагрузок. Установите tmpfs upper-bound немного меньше, чем сумма свободной swap и RAM при пиковой нагрузке.
Создать tmpfs с лимитом на максимальный размер достаточно просто. Например:
# mount tmpfs /dev/shm -t tmpfs -o size=32m
В этом примере монтирование новой tmpfs происходит не к точке /mnt/tmpfs, а к специально созданному /dev/shm. Это каталог, который является официальной точкой монтирования ("official" mountpoint) для tmpfs. Если вы используете devfs, этот каталог будет создан автоматически.
Если требуется ограничить размер файловой системы в оперативной памяти 512 КБ или 1 GB, можно соответственно указать size=512k или size=1g. В дополнение к ограничению размера можно лимитировать число inodes (filesystem objects) через параметр nr_inodes=x. Где x - целое число, возможно, с суффиксом k, m или g для обозначения тысяч, миллионов или миллиардов inodes.
Для автоматического монтирования при загрузке системы допустимо сделать запись в файле /etc/fstab. Например:
tmpfs /dev/shm tmpfs size=32m 0 0
Режим 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=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=writeback
В режиме data=writeback, файловая система ext3 не выполняет какого либо журналирования данных. С подобным видом журналирования вы имеете дело в файловых системах XFS, JFS и ReiserFS (журналирование только метаданных). Как объяснялось впредыдущих статьях, это не защитит от разрушения данные в обновляемых файлах в случае неожиданной перезагрузки. Несмотря на этот недостаток, режим data=writeback обеспечивает самую высокую производительность ext3 при всех условиях.
Результаты.
Тестирование показало, что XFS очень быстрая файловая система. XFS - постоянный лидер в тестах с манипуляциями большими файлами. Собственно такой результат вполне предсказуемый (она и проектировалась именно под это). Была замечена одна "причуда" в производительности - относительно медленные операции удаления файлов. В этом вопросе она проиграла и ReiserFS, и ext3. По замечанию Стива Лорда (Steve Lord - Principal Engineer по файловым системам в SGI) недавно был написан патч, решающий эту проблему (будет доступен в ближайшее время).
В других тестах производительность XFS была близка к таковой у ReiserFS и всегда превосходила ext3. Приятная особенность XFS - она не генерирует (впрочем, как и ReiserFS) излишнюю дисковую активность. XFS пытается кэшировать как можно больше данных и "основанием" для сброса на диск является заполнение памяти, а не интервал времени. Когда происходит сброс данных на диск, это не оказывает заметного влияния на другие операции ввода/вывода. Как противоположность - в ext3 (режим "data=ordered") периодический сброс данных на диск порождает проблемы с интерактивностью и, при высокой интенсивности операций ввода/вывода, даже блокирование диска.
Следующие тесты на производительность и адаптацию к внешним факторам сосредоточились вокруг распаковки тарбалла исходников ядра Linux на RAM disk и последующее рекурсивное копирование дерева исходников в новый каталог на той же файловой системе. XFS справлялась с такой задачей хорошо, но проигрывала ReiserFS. Однако, после повторного mkfs.xfs и игры с опциями mount, XFS смогла немного "обойти" по скорости ReiserFS даже при обработке файлов среднего размера, характерных для исходников ядра. Словом, преимущество почти во всем, кроме маленькой детали - удаления старых файлов, "неудобной" для XFS операции (ReiserFS и ext3 удаляют файлы быстрее, чем XFS).
Руководство по продвинутым файловым системамПрезентация ReiserFS
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник:
Июль 2001
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник:
Декабрь 2001
Я хочу быть честным. В этой статье я планировал описать установку и настройку ext3 на вашей системе. Хотя такая цель была обозначена, это не совсем то, о чем пойдет разговор. У Эндрю Мортона (Andrew Morton) имеется превосходная страница , что делает простое объяснение перехода на ext3 излишним (зачем повторять то, что прекрасно описано у других). Вместо этого я собираюсь обратить ваше внимание на неожиданные стороны использования ext3 и, думаю, это будет полезным для вас. После прочтения этой статьи вы будете готовы к более осознанному переходу на ext3, чем в случае "пересказа" страницы Эндрю. По крайней мере, я на это надеюсь.
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник :
Январь, 2002
В этой статье мы познакомимся с XFS, SGI's free, 64-bit, высокопроизводительной файловой системой для Linux. Сначала будет проведено сравнение XFS с ext3 и ReiserFS и описаны некоторые из технологий, которые используют внутренние структуры XFS. В следующей статье будет описан процесс инсталляции XFS на вашей системе и даны несколько советов по настройке XFS и ее полезных features, например ACL (access control lists) и поддержки extended attribute.
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник :
Апрель, 2002
В этой статье будет показано, как добавить поддержку XFS к вашей системе. Но сначала посетите и исследуйте . Если проследуете по ссылкам, вы найдете патчи, инструментарий и даже ядро от Red Hat, поддерживающее XFS.
Но не торопитесь. Конечно, можно инсталлировать XFS используя pre-rolled, т.е. официальные релизы. Но в данном случае я не рекомендую такой подход. При написании этой статьи самый последним из официальных релизов XFS был 1.0.2, созданный еще в ноябре 2001. С того времени было внесено множество уточнений к XFS и, чтобы извлечь из этого выгоду, воспользуемся современными исходниками из XFS CVS-дерева. Developers и users, сделавшие выбор в пользу Gentoo Linux и воспользовавшиеся XFS из CVS, получили от XFS много больше.
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник :
Июнь 2002
Просматривая свои прошлые статьи из серии "Руководство по "продвинутым" файловым системам" для себя я отметил, что со времени первой публикации прошел почти год! Не волнуйтесь, эта серия скоро пополнится новым содержанием, поскольку я собираюсь приступить к описанию Linux технологий JFS и EVMS (enterprise volume management) от IBM. Поскольку площадкой для публикаций является сайт IBM, я решил, что описание технологий от IBM уместно сделать после всех остальных файловых систем для Linux.
Но, прежде чем приступить к JFS и EVMS, я отвлекусь на вопросы апдейта текущего состояния файловых систем в мире Linux. Мы опробовали большое число ядер серии 2.4. Одни из них были оценены как "приличные", о других такого не говорили. Не только ядро, но и XFS, ext3 и ReiserFS находились в состоянии активного развития. При этом, большое число пользователей использовали самые разные комбинации файловых систем XFS, ext3 и ReiserFS и с разными результами. Когда кто либо из пользователей Gentoo Linux имеет проблему с журналируемой файловой системой, обычно я об этом узнаю. Итак, какие файловые системы стали наиболее популярными? Какие из их числа наиболее надежны? В этой статье я воспользуюсь результатами обратной связи с пользователями и информацией от development команд ReiserFS, ext3 и XFS.
Вот именно на этом сайте и стал Владимир Холманов размещать свои переводы статей Дэниела Роббинса, да и собственные оригинальные материалы - тоже. И все шло хорошо, пока в один не очень прекрасный день Александр не потерял возможности далее развивать и поддерживать свой сайт (на причинах этого останавливаться не буду). И вот уже более двух лет никаких обновлений на не происходит. Хотя сам сайт и жив - но сколь долго это будет продолжаться, одному Аллаху ведомо.
Именно беспокойство за судьбу контента сайта и побудило редакцию к переразмещению некоторых его материалов. Почему первыми из них оказались труды Дэниела? Конечно, некоторые части его цикла устарели безнадежно - это касается статей про devfs - к счастью пользователей, уже практически во всех дистрибутивах Linux она окончательно вытеснена механизмом udev. Показаться потерявшими актуальность могут и некоторые соображения Роббинса относительно ReiserFS. Однако все, что касается XFS, сохраняет актуальность в полном объеме. Да и Ext3fs вряд ли претерпела кардинальные изменения. В общем, могу констатировать: нынче на форумах не редки вопросы, ответы на которые можно найти в старых статьях Дэниела.
Как можно видеть из приводимого ниже оглавления, части цикла, посвященные devfs, изъяты как утратившие актуальность. Прочие же приводятся в том виде, как они были размещены первично, с минимальной редакторской правкой.
В размещаемых материалах тоже содержатся некоторые моменты, которые могут выглядеть совсем несовременными. Например, рассуждения Дэниела о том, какие версии ядра ветки 2.4 (уходящей в историю) окажутся более подходящими для работы с той или иной из "продвинутых" файловых систем. Тем не менее, я не счел для себя возможным полностью изъять такие пассажи: кроме всего прочего, они представляют интерес для истории, так как написаны очевидцем (и участником) событий. Хотя кое-где я и позволил себе сократить материал.
Руководство по продвинутым файловым системам Дэниела Роббинса Вместо вступления: зачем оно нужно?
Это - цикл статей Дэниеля Роббинса, посвященный файловым системам Linux. Опубликован он достаточно давно (в 2001-2002 годах), и может возникнуть естественный вопрос: за каким таким сиреневым переразмещать это старье? Постараюсь ответить.
В некотором царстве, некотором государстве (а конкретно - в солнечной Невадщине) жил да был парень один. Звали его Дэниел Роббинс. Учился он в местном университете, а на досуге занимался всякими Unix'ами: поучаствовал в разработке FreeBSD, был одним из разработчиков проекта Stampede Linux... А потом взял и изобрел свой дистрибутив, который назвал Gentoo, быстро ставший очень популярным.
Впрочем, о Gentoo знают все, имевшие дело с Linux (а кто не знает - может узнать о нем на официальном сайте, , там и по русски немало написано). А вот о том, что Дэниел был еще и талантливым техническим писателем, нынешнее поколение линуксоидов начинает забывать. И писал он о массе вещей, интересных как IT-специалисту, так и конечному пользователю: о командной оболочке bash и о программных RAID-массивах, о программе awk и об управлении логическими томами (LVM), о редакторе sed и политике управления дисковыми разделами (полный список его статей можно найти на , поиском по ключевому слову Robbins).
Написал Дэниел и цикл статей о файловых системах, поддерживаемых последними, на тот момент, версиями ядра Linux, который поэтому и получил общий заголовок: Advanced filesystem implementor's guide. Очень интересный цикл получился - но тут уже начинается вторая часть нашей истории.
Потому что в то же самое время в несколько менее солнечной Российщине жил другой парень, которого звали Владимир Холманов. И который тоже любил ковыряться в Linux'е. А еще знал он английский язык. И потому взялся за переводы статей Дэниела. Которые размещал... Впрочем, где он их размещал - это третья часть нашей истории. А пока замечу, что занимался Владимир не только переводами, но и собственные статьи сочинял - например, про использование LVM.
Так вот, третий персонаж нашей истории - Александр Благин, проживавший в древнем и славном городе Ярославле. Он тоже неровно дышал к Linux'у, и потому создал сайт - . На котором стал собирать всю доступную русскоязычную документацию по этой операционке. Коллекция его все росла и росла, пока не набралось ее на хороший сидюк, мегабайт на 600-700. Если учесть, что была она в pure html, можете представить себе, сколько там всего было. Благодаря этому сайт снискал заслуженную любовь пользователей (тех, которые не утратили привычки к чтению), хотя и не фигурировал никогда во первых строках всякого рода пузомерок. Кстати, именно Александру Благину принадлежит бессмертная фраза: "Место таких сайтов, как этот, не в рейтингах топ-листов, а в кэшах поисковиков и в закладках пользователей".
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник :
Август 2001
В этой статье я опишу процесс установки ReiserFS с ядром 2.4. Одновременно будут затронуты "технические" аспекты, касающиеся ядра 2.4 и его сопряженности с ReiserFS, вопросы производительности и т.п. Так как инсталляция будет описана в начале, я рекомендую прежде прочесть всю статью, и лишь потом перейти к практике. Полезно сразу ознакомиться с техническими примечаниями, поскольку при установке ReiserFS на вашу систему такое знание поможет снять ряд вопросов.
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник :
Сентябрь 2001
В предыдущих статьях этой серии я описал преимущества журналирования вообще и файловую систему ReiserFS в частности. Была описана процедура ее установки. В данной статье обратим свое внимание на нетривиальную тему. Сначала будет рассмотрена tmpfs, еще известная как файловая система в virtual memory (VM). Tmpfs - вероятно лучшая RAM disk-like система, уже сейчас доступная для Linux через новые свойства ядра 2.4. После начального вступления рассмотрим дополнительные возможности ядра 2.4, называемые "bind mounts", которые добавляют много гибкости в монтировании файловых систем.
Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука
Первоисточник :
Ноябрь 2001
В прошлых статьях имелся обзор нетрадиционных файловых систем типа tmpfs. Теперь пришло время вернуться к файловым системам на блочных устройствах (disk-based), и это делается на примере ext3. Файловая система Ext3, разработанная доктором Стефеном Твиди (Dr. Stephen Tweedie), сформирована на структурах существующей файловой системы ext2; фактически, ext3 очень похожа на ext2 за исключением маленького (но важного) отличия - она поддерживает journaling. После такого "маленького" добавления в ext3 появились некоторые удивительные и интригующие возможности. В этой статье дается сравнение ext3 с другими journaling filesystems, доступными для использования уже сегодня. Планируется выход еще одной статьи об использовании ext3.
Создание и монтирование файловой системы.
После перезагрузки вы сможете создать файловую систему ReiserFS на пустом partition следующей командой:
# mkreiserfs /dev/hdxy
В этом примере /dev/hdxy - device node, соответствующий свободному partition. Монтирование аналогично любой другой файловой системе:
# mount /dev/hdxy /mnt/reiser
Добавить файловую систему ReiserFS в файл /etc/fstab можно при установке полей "freq" и "passno" в значение "0", например:
/dev/hdc1 /home reiserfs defaults 0 0
Начиная с этого момента ваша ReiserFS внешне становится тождественной ext2. Вы быстро забудете об изнурительном "fsck", а данные станут доступны быстрее, особенно из маленьких файлов.
До недавнего времени выбор файловой
До недавнего времени выбор файловой системы для Linux был ободряюще прямым. Те, кому требовалась высокая производительность, склонялись к ReiserFS, а те, кого волновала целостность данных, предпочитали ext3. С появлением поддержки XFS для Linux выбор стал не столь прямолинеен. В частности, большой вопрос, а действительно ли ReiserFS при всех условиях является лидером по производительности?
Недавно мной было проведено тестирование с целью сравнения XFS, ReiserFS и ext3 в отношении "чистой" производительности. Но, прежде всего я замечу, что результаты отражают только общую тенденцию зависимости производительности файловых систем от нагрузки на однопроцессорной системе. Тесты, не претендуя на "абсолютную" истинность результатов, тем не менее, могут помочь в ответе на вопрос: для какой специфической задачи какой файловой системе следует отдавать предпочтение. И еще раз, результаты моего тестирования не рассматривайте как заключительные. В любом случае, для ответственного выбора следует проводить тестирование на конкретных приложениях.
Стабильность файловой системы.
Я использовал 2.4.4 с ReiserFS на промышленном сервере в течение месяца (на cvs.gentoo.org development сервере) без каких-либо проблем. 2.4.4 и 2.4.4-ac9 зарекомендовали себя надежными. Сервер сильно загружен операциями IO, так как на нем хранятся cvs архив нашего , почтовый сервер gentoo.org, списки рассылки и другое.
Технология ReiserFS
За счет чего ReiserFS эффективно работает с маленькими файлами? ReiserFS использует специально оптимизированные сбалансированные деревья (b* balanced tree - одно на файловую систему) для организации всех данных файловой системы. Одно это дает большое увеличение производительности, а также снимает ряд искусственных ограничений на размещение файловой системы. Например, становится возможным иметь каталог, содержащий 100,000 других подкаталогов. Еще одна выгода от использования b*tree в том, что ReiserFS, подобно большинству других filesystems нового поколения, динамически ассигнует информационные узлы (inodes) вместо их статического набора, образующегося при создании "традиционной" файловой системы. Это дает большую гибкость и оптимальность в формировании пространства хранения.
ReiserFS также имеет ряд особенностей, нацеленных специально для улучшения работы с маленькими файлами. ReiserFS не связана ограничением в ассигновании памяти для файла в целом числе 1-2-4 KB блоков. По необходимости для файла может ассигноваться точный размер. ReiserFS также включает некоторые виды специальной оптимизации файловых "хвостов" для хранения конечных частей файлов, меньших, чем логический блок файловой системы. Для увеличения скорости, ReiserFS способен хранить содержимое файлов непосредственно внутри дерева b*tree, а не в виде указателя на дисковый блок (в ext2 есть понятие fastlink, когда содержимое "мягкой" ссылки до 60 байт хранится в inode).
Тем самым достигается две вещи. Первое, сильно увеличивается производительность, так как данные и метаданные (stat_data, иначе говоря, inode) информация может хранится рядом и считываться одной дисковой операцией ввода/вывода. Второе, ReiserFS способен упаковать хвосты (tail) файлов, экономя дисковое пространство. Фактически, при разрешении ReiserFS выполнять упаковку хвостов (значение по умолчанию) будет экономиться примерно шесть процентов дискового пространства (в сравнении с ext2).
Следует иметь в виду, что упаковка хвостов требует дополнительной работы, так как при изменении размеров файлов необходима "переупаковка". По этой причине в ReiserFS упаковка хвоста может отключаться, позволяя администратору выбрать между скоростью и эффективностью использования дискового пространства.
ReiserFS - превосходная файловая система. В следующей статье будет описан процесс инсталляции ReiserFS под Linux 2.4. Будет описана процедура оптимальной настройки под требования приложений, опции ядра и другое.
The ac9 patch and bigpatch
Можно использовать простое 2.4.4 ядро, в нем все имеется. Однако я рекомендую применить следующие ac и bigpatch patches.
Для apply the ac9 patch, получите из kernel.org и выполните:
# cd /usr/src/linux # bzip2 -dc /path/to/patch-2.4.4-ac9.bz2 | patch -p1
Наложив такой patch (или оставив все без изменений), получите и ReiserFS . Опять же, этот шаг необязателен, но мною рекомендованный, особенно для NFS сервера и поддержки квот (даже если это вам не нужно, patch не навредит). Для наложения bigpatch выполните:
# cd /usr/src/linux # bzip2 -dc /path/to/bigpatch-2.4.4.diff.bz2 | patch -p1
Выполнив один, оба или ни одного шага, вы готовы к конфигурированию ядра для ReiserFS.
Обратите внимание: если вам требуется помощь в компиляции ядра, есть хорошая, свободно распространяемая обучающая программа на developerWorks. Далее очень кратко.
Конфигурирование ядра весьма просто. Сначала выполняем "make menuconfig". В секции "Code maturity level options" убедитесь, что опция "Prompt for development and/or incomplete code/drivers" - enabled. Переходим в секцию "File systems" и enable "ReiserFS support". Вы должны конфигурировать поддержку ReiserFS для компилирования непосредственно в ядро, а не как модуль. Теперь не помешает разрешить "Have reiserFS do extra internal checking". Сохраните конфигурацию и компилируйте ядро ("make dep; make bzImage; make modules; make modules_install") и добавьте запись в ваш загрузчик для ReiserFS-enabled kernel.
Важно: никогда не удаляйте ваше текущее ядро, не убедившись в работоспособности нового.
Tmpfs и VM
Давайте посмотрим на некоторые наиболее интересные свойства tmpfs. Как было отмечено выше, tmpfs может использовать и RAM, и swap. На первый взгляд, это может показаться не принципиальным, но вспомните, tmpfs еще известна как файловая система в виртуальной памяти (virtual memory filesystem). Возможно, вы знаете, что ядро Linux "понимает" ресурс "виртуальная память" именно как единое - целое RAM и swap-пространство. Подсистема VM ядра ассигнует эти ресурсы другим подсистемам и управляет этими ресурсами behind-the-scenes (прозрачно в фоне). При этом часто без ведома "подсистемы - заказчика" перемещает страницы ОПЕРАТИВНОЙ ПАМЯТИ между собственно RAM и swap.
Файловая система tmpfs запрашивает страницы у подсистемы VM для хранения файлов. При этом сама tmpfs не знает, находятся ли эти страницы в swap или в RAM; это - "проблема" VM подсистемы. Иначе говоря, tmpfs знает лишь то, что она использует виртуальную память.
Уход от low VM conditions
А чего это мы все говорим о достоинствах? Фактом является то, что tmpfs динамически растет и уменьшается. Поэтому естественен провокационный вопрос. А что случится, если tmpfs filesystem разрастется так, что поглотит всю виртуальную память? Скажем так, приемлемое решение еще не найдено. С ядром 2.4.4, увы, произошло бы зависание. С ядром 2.4.6, подсистема VM имеет некоторую защиту, и авария не произойдет. Когда 2.4.6 почувствует точку, за которой ассигнование дополнительной памяти проблематично, вы просто не сможете ничего более записать в tmpfs filesystem. Кроме того, произойдут некоторые другие вещи. Сначала процессы в системе не смогут ассигновать дополнительную память; внешне система станет очень вялой. У суперпользователя есть время, чтобы предпринять шаги для выхода из low-VM condition.
Далее, ядро имеет встроенную last-ditch систему освобождения памяти при ее исчерпании; она находит процесс, который наиболее "жадно" потребляет VM ресурсы и уничтожает его. К сожалению, такое "kill a process" решение имеет неприятные последствия, особенно, если в истощении памяти виновата tmpfs. Причина вот в чем. Сама tmpfs уничтожена быть не может, так как она - часть ядра, а не пользовательский процесс. Кроме того, специфика tmpfs такова, что для ядра не существует простого способа выяснить, какой именно процесс "затопляет" tmpfs. В таких случаях ядро ("вот разберусь до конца и накажу, кого попало") по ошибке "убивает" самый большой VM-hog процесс, которым обычно является ваш X server. Определить, что истинной причиной "падения" X было low-VM condition (tmpfs) очень сложно.
Введение в журналирование: метаданные
Начнем с банального. Файловые системы существуют для того, чтобы хранить, находить и манипулировать данными. Для выполнения таких задач сама файловая система должна иметь внутреннюю "управляющую" структуру, которая позволяет все это делать. Такая внутренняя структура ("the data about the data") называется метаданными (meta-data). От организации метаданных зависят рабочие характеристики файловых систем (и это то, чем файловые системы друг от друга отличаются).
Обычно с такими метаданными сам пользователь не взаимодействует. Вместо этого с ними работает драйвер файловой системы. Драйвер фацловой системы Linux специально разработан для управления этим лабиринтом метаданных. Однако, для функционирования драйвера имеется одно важное требование; он ожидает видеть метаданные в разумном, непротиворечивом, не разрушенном состоянии. В противном случае обращение к файлам становится невозможным.
Введение в журналирование: утилита fsck
Поговорим о fsck. Где-то в начале загрузки Linux запускается fsck и начинается сканирование всех локальных файловых систем (перечислены в /etc/fstab). Делается это для того, чтобы гарантировать непротиворечивостьметаданных и, в конечном счете, возможность монтирования файловой системы. Такое сканирование занимает много времени и, в целях "экономии", предполагается следующее. Если Linux завершает работу корректно, то сброс на диск всех кэшированных данных происходит "штатно". В таком случае есть гарантия, что файловая система размонтирована "чисто" и готова к очередному монтированию. Как правило, fsck ограничивается только проверкой "флага чистого размонтирования" (clean byte) и, если проблем нет, делает разумное предположение, что с метаданными все в порядке.
Однако все мы знаем, что происходят и аварийные ситуации вследствие сбоя в питании или глубокого зависания системы. В таких ситуациях о "чистом размонтировании" со сбросом всех кэшированных данных на диск речи не идет. Если такое происходит, очередной запуск fsck обнаруживает это и делается разумный вывод, что файловая система, вероятно, не готова к взаимодействию с драйвером. Очень может быть, что метаданные находятся в противоречивом состоянии.
Чтобы ликвидировать возможные последствия, fsck начнет полное сканирование и проверку непротиворечивости метаданных, по ходу исправляя многие ошибки. В большинстве случаев после "сканирования с исправлениями" файловая система готова к монтированию. Следует понять, что способность к монтированию еще не означает целостность самих данных.
Выводы по производительности
Сказанного достаточно для понимания общей идеи относительно ожиданий производительности от XFS. Результаты тестирования подтвердили, что XFS лучший выбор среди файловых систем, если требуются манипуляции с большими файлами. При работе с файлами среднего размера XFS вполне конкурентоспособна, а в ряде случаев даже немного быстрее ReiserFS. Последнее справедливо, если создавать и монтировать XFS с некоторыми performance-enhancing опциями. Ext3 в режиме "data=journal" показывает сравнительно неплохую производительность с учетом гарантии целостности данных (а не только метаданных). Однако дать по настоящему высокую оценку ext3 мешают проблемы при сбросе данных на диск.
Я нахожу, что ReiserFS очень
Я нахожу, что ReiserFS очень приятная файловая система и дает выигрыш не только на маленьких, но и на больших файлах по сравнению с ext2. Благодаря ReiserFS разработчикам требуется только 15 секунд для модификации CVS Gentoo Linux, притом, что на ext2 это занимало около 2 минут. ReiserFS делает работу более комфортной и позволяет нашему cvs серверу одновременно обрабатывать большее число IO без потери интерактивности.
Притом, что она уже сегодня производит впечатление, будущее представляется еще более интересным. Ханс Райзер имеет очень агрессивный творческий план относительно ReiserFS. Со временем можно ожидать, что ReiserFS станет больше чем "другая высокоэффективная файловая система". Это должно открыть новые возможности и подходы для решения традиционных проблем хранения информации. С Namesys можно связывать и будущее развитие Linux.
В настоящее время многие пытаются определиться, какая из поддержанных в Linux журналируемых файловых систем является "лучшей". По большому счету, все определяется тем, для каких целей и каких приложений файловую систему планируется использовать; каждая имеет свои достоинства и недостатки. Безусловное преимущество пользователей Linux - возможность выбора между файловыми системами нового поколения. Вместо приклеивания ярлыка "лучшей" файловой системы, следует понять силу и слабость каждой и принять обоснованное решение.
Ext3 имеет множество преимуществ. Она разработана для максимальной простоты развертывания. Она основана на годами проверенном коде ext2 и получила "по наследству" замечательный инструментарий fsck. Ext3 в первую очередь предназначена для приложений, не имеющих встроенных возможностей по гарантированию сохранности данных. В целом, ext3 - замечательная файловая система и достойное продолжение ext2. В моей следующей статье будет описана установка и работа с ext3.
Об ext3 хватит. Приглашаю к чтению моей следующей статьи, поскольку речь пойдет о многих чудесах ... XFS!
Я надеюсь, вам понравился рассказ о производительности и технических характеристиках XFS, одной из самых мощных файловых систем Linux нового поколения. Тогда приглашаю к чтению следующей статьи, где пойдет разговор о вещах практических. В планируемой статье будут также рассмотрены некоторые "продвинутые" особенности XFS, например ACLs и расширенные атрибутыs. До встречи!
о том, как файловая система
Теперь можно поговорить о том, как файловая система ext3 обеспечивает журналирование и данных, и метаданных. Фактически в ext3 имеются два метода достижения гарантии непротиворечивости.
Первоначально ext3 разрабатывалась для журналирования и всех данных, и метаданных. В этом режиме (называется "data=journal" mode), JBD журналирует все изменения в файловой системе, связанные как с данными, так и с метаданными. При этом JBD может использовать журнал для отката и восстановления метаданных и данных. Недостаток "полного" журналирования в достаточно низкой производительности и расходе большого объема дискового пространства под журнал.
Недавно для ext3 был добавлен новый режим журналирования, который сочетает высокую производительность и гарантию непротиворечивости структуры файловой системы после сбоя (как у "обычных" журналируемых файловых систем). Новый режим работы обслуживает только метаданные. Однако драйвер файловой системы ext3 по-прежнему отслеживает обработку целых блоков данных (если они связаны с модификацией метаданных), и группирует их в отдельный объект, называемый тразакцией (transaction). Транзакция будет завершена только после записи на диск всех данных. "Побочный" эффект такой "грубой" методики (называемой "data=ordered" mode) - ext3 обеспечивает более высокую вероятность сохранности данных (по сравнению с "продвинутыми" журналируемыми файловыми системами) при гарантии непротиворечивости метаданных. При этом происходит журналирование изменений только структуры файловой системы. Ext3 использует этот режим по умолчанию.
Журнал
Журналируемые файловые системы снимают проблему fsck через дополнительную стуктуру данных (data structure), называемую журналом. Такой журнал - on-disk structure. Прежде, чем драйвер файловой системы сделает любое изменение в метаданных, делается запись в журнал с описанием предстоящих действий. Только после этого происходит изменение самих метаданных. Таким образом, журналируемая файловая система обслуживает регистрационный файл последних модификаций метаданных. Затраты на ведение такого журнала несравненно ниже, чем сканирование всей файловой системы на предмет непротиворечивости метаданных.
Представьте себе цепочку - хранящиеся данные (stuff), "данные об этих данных" (the data about the stuff) - собственно метаданные, и журнал с метаданными о метаданных (the data about the data about the stuff).
Журналирование
Разумеется, как и большинство современных файловых систем, XFS поддерживает журналирование метаданных для быстрого восстановления в случае аварийной перезагрузки. Подобно ReiserFS, в XFS используется логическое журналирование. Иначе, журнал ведется не файловыми блоками (как в ext3), а в эффективном дисковом формате с регистрацией только изменяемых метаданных. Для XFS логическое журналирование особенно "показано". На высококлассном оборудовании (что обычно для XFS) журнал наиболее спорный ресурс. Использование ограниченного по размеру логического журнала минимизирует непроизводительное расходование ресурсов. Кроме того, XFS допускает хранение журнала на другом блочном устройстве (partition, скажем так, на "дешевом" диске). Эта особенность не только экономит дорогие ресурсы, но в еще большей степени "работает" на увеличение скорости XFS.
Как и ReiserFS, XFS журналирует только метаданные и не делает это для самих данных. Из этого следует, что в XFS (как и в ReiserFS) возможна потеря данных, измененных перед аварийной перезагрузкой. Но, у журнала XFS имеется два свойства, снижающих вероятность потери данных по сравнению с ReiserFS.
В ReiserFS неожиданная перезагрузка может иметь результатом попадание в изменяемый файл фрагмента из когда-то удаленного файла. Помимо очевидной потери данных, гипотетически это может иметь более серьезные последствия. В XFS имеется гарантия, что любые "недозаписанные" блоки заполнены нулями. Так как блоки с нулевыми байтами в системных файлах игнорируются, устраняется лазейка в безопасности.
Теперь непосредственно о проблеме потери данных. Такая проблема в XFS минимизируется вследствие того, что операция сброса на диск ожидающих обработки модификаций метаданных в XFS происходит чаще, чем это происходит в ReiserFS (особенно при высокой интенсивности операций IO). Как следствие, после аварии в XFS потерь будет меньше, чем при тех же условиях в ReiserFS. Заметьте, сама по себе более частая запись метаданных не "купирует" проблему, а лишь провоцирует более частый сброс на диск и самих данных.
Журналирование только метаданных
Интересно то, что ext3 выполняет журналирование совсем иначе, чем ReiserFS и другие журналируемые файловые системы. В ReiserFS, XFS и JFS журналируются метаданные их и не предусмотрено какое либо журналирование самих данных. При при журналировании метаданных (metadata-only journaling) метаданные хранятся так надежно, что, скорее всего вам не придется пользоваться fsck. Однако, неожиданные перезагрузки и сбои в электропитании могут приводить к утере данных, которые в момент сбоя записывались на диск. Ext3 использует несколько творческих решений для избежания таких проблем.
Сначала поясним ситуацию с журналированием только метаданных. Например, вы редактировали файл /tmp/myfile.txt в момент, когда машина неожиданно блокировалась. В случае с журналируемыми системами, журналирующими только метаданные (например, ReiserFS, XFS или JFS), метаданные вашей файловой системы утрачены не будут и запуска fsck не потребуется.
Однако, в случае такого сбоя имеется высокая вероятность, что в файле /tmp/myfile.txt останется один мусор, а то и просто он станет нечитабельным.
Причина в следующем. "Обычные" журналируемые файловые системы, подобные ReiserFS, XFS и JFS опекают метаданные, но для повышения производительности заботу о данных не проявляют. В нашем примере происходила модификация некоторых блоков и соответствующих им метаданных, но синхронизация была неожиданно прервана. "Непротиворечивость" файловых блоков будет восстановлена, чего нельзя сказать об их "наполнении".
Журналирование в действии
А что же делает fsck на журналируемой файловой системе? Обычно - ничего. Он просто "не видит" файловую систему и разрешает ее монтирование. Реальное волшебство быстрого восстановления файловой системы в непротиворечивое состояние ложится на драйвер файловой системы. Когда файловая система монтируется, он, сиречь драйвер, выясняет, все ли было в порядке. Если "чистого размонтирования" не было и метаданные должны быть исправлены то, вместо выполнения полного сканирования (как это делает fsck), драйвер читает журнал. Так как в журнале содержится хронология всех последних изменений метаданных, выполняется просмотр мизерной части meta-data. Вопрос о приведении файловой системы в непротиворечивое состояние решается в течение долей, максимум нескольких секунд. В отличие от традиционного (на сегодняшний день) подхода, время восстановления не зависит от размера файловой системы (зависит от интенсивности операций ввода/вывода (IO) в момент, предшествующий краху). Благодаря журналу снимаются многие проблемы, ставшие препятствием на пути увеличения размеров файловых систем.
когда имеется общее понимание проблемы,
Теперь, когда имеется общее понимание проблемы, посмотрим, как ext3 осуществляет журналирование. В коде журнализации для ext3 используется специальный API, называемый Уровень журналирования блочного устройства (Journaling Block Device layer или JBD). JBD был разработан для журнализации на любых блочных устройств. Ext3 привязана к JBD API. При этом код файловой системы ext3 сообщает JBD о необходимости проведения модификации и запрашивает у JBD разрешение на ее проведение. Журналом управляет JBD от имени драйвера файловой системы ext3. Такое соглашение очень удобно, так как JBD развивается как отдельный, универсальный объект и может использоваться в будущем для журналирования в других файловых систем.
Имеется два важных момента в управлении журналом ext3 через JBD, вытекающих из хранения журнала в inode файле (в базовом варианте). Первое, в зависимости от ключей монтирования файловой системы ext3, этот файл можно "видеть" или "не видеть" (расположен в /.journal). Второе, такое хранение журнала делает возможным переход к ext3 через простое добавление единственного файла (и замену драйвера) без использования несовместимых расширений к метаданным ext2. Это ключ к пониманию "обратной совместимости" файловой системы ext3 с ext2 метаданными и "прямой совместимости" ext2 с ext3 драйвером.
