Daniel Robbins (drobbins@gentoo.org)
President/CEO
June 2001
С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. Daniel Robbins отвечает на эти вопросы по ходу пояснения инсталляции этих новых продвинутых filesystems под Linux 2.4. В этой, первой статье из цикла, даются пояснения по journalling вообще и ReiserFS в частности.
Что следует ожидать от прочтения этого цикла статей.
Цель этого цикла состоит в том, чтобы дать твердое, практическое введение в новые файловые системы для Linux, такие как ReiserFS, XFS, JFS, GFS, ext3 и другие. Я хочу "вооружить" читателя практичным взглядом на эти вещи и подготовить к осознанному использованию новых файловых систем. Цель так же в том, чтобы помочь Вам (насколько это возможно) избежать многих потенциальных ловушек. Иначе, предлагается осторожный просмотр файловых систем с позиций стабильности, производительности (плюсов и минусов), любых отрицательных воздействий на приложения, анализ комбинаций kernel/patch и т.п. Рассматривайте цикл статей как "insider's guide" для файловых систем нового поколения.
Это то, что следует иметь в виду. Однако, открывая цикл, я несколько отвлекаюсь от поставленной "практической" цели и отвлекаюсь на небольшое "теоретическое" вступление. Далее будут охвачены две темы, очень важные для Linux development community - "журнализация" и "техническая" точка зрения на проект ReiserFS. Journalling - технология, которую долго ждали, и пришло время ее практического использования. На этой технологии работают ReiserFS, XFS, JFS, ext3 и GFS. Важно точно понять, что собственно делает journalling и почему Linux в ней нуждается. Даже если вам это хорошо известно, я надеюсь, что мое journalling intro вам будет полезно. Это хорошая "рыба" для объяснения технологии другим и кое-что для практики. Часто процесс внедрения нового приходится начинать с "Linux guy/gal", убеждая других в необходимости "качественного скачка".
Во второй части статьи рассматриваются технические аспекты ReiserFS. Делается это для демонстрации того факта, что новые файловые системы делают ту же работу, что и "традиционные", но часто немного быстрее. Они также позволяют выполнять работу способами, прежде невозможными. Первая статья важна для понимания всего цикла. Возможности новых файловых систем, вероятно, затронут будущее развитие Linux.
Введение в journalling: meta-data
Начнем с банального. Файловые системы существуют для того, чтобы хранить, находить и манипулировать данными. Для выполнения таких задач сама файловая система должна иметь внутреннюю "управляющую" структуру, которая позволяет все это делать. Такая внутренняя структура ("the data about the data") называется meta-data. От организации этих meta-data зависят рабочие характеристики файловых систем (и это то, чем файловые системы друг от друга отличаются).
Обычно с такими meta-data сам пользователь не взаимодействует. Вместо этого с ними работает драйвер файловой системы. Linux filesystem driver специально разработан для управления этим лабиринтом метаданных. Однако, для функционирования драйвера имеется одно важное требование; он ожидает видеть метаданные в разумном, непротиворечивом, не разрушенном состоянии. В противном случае обращение к файлам становится невозможным.
Поговорим о fsck. Где-то в начале загрузки Linux запускается fsck и начинается сканирование всех локальных файловых систем (перечислены в /etc/fstab). Делается это для того, чтобы гарантировать непротиворечивость meta-data и, в конечном счете, возможность монтирования файловой системы. Такое сканирование занимает много времени и, в целях "экономии", предполагается следующее. Если Linux завершает работу "корректно", то сброс на диск всех кэшированных данных происходит "штатно". В таком случае есть гарантия, что filesystem размонтирована "чисто" и готова к очередному монтированию. Как правило, fsck ограничивается только проверкой "флага чистого размонтирования" и, если проблем нет, делает разумное предположение, что с meta-data все OK.
Однако все мы знаем, что происходят и аварийные ситуации вследствие сбоя в питании или глубокого зависания системы. В таких ситуациях о "чистом размонтировании" со сбросом всех кэшированных данных на диск речи не идет. Если такое происходит, очередной запуск fsck обнаруживает это и делается разумный вывод, что filesystems, вероятно, не готова к взаимодействию с драйвером. Очень может быть, что meta-data находятся в противоречивом состоянии.
Чтобы ликвидировать возможные последствия, fsck начнет полное сканирование и проверку непротиворечивости метаданных, по ходу исправляя многие ошибки. В большинстве случаев после "сканирования с исправлениями" файловая система готова к монтированию. Следует понять, что способность к монтированию еще не означает целостность самих данных.
Нельзя сказать, что описанное - плохой подход к обеспечению целостности файловой системы, но решение не оптимально. Не оптимальность результат того, что fsck должен просканировать все метаданные файловой системы для вывода об их непротиворечивости. Выполнение полной проверки всех метаданных задача сама по себе трудоемкая. К этому следует добавить, что с увеличением размера файловой системы затраты на полное сканирование растут прогрессивно (на персональной машине это может занять несколько минут, на сервере полчаса и больше). И еще, стандартное поведение fsck предполагает периодически проверки после некоторого числа "чистых размонтирований", что не может считаться приемлемым для mission-critical datacenter, когда "время - деньги". К счастью, имеется лучшее решение.
Журналируемые файловые системы снимают проблему fsck через дополнительную data structure, называемую журналом. Такой журнал - on-disk structure. Прежде, чем драйвер файловой системы сделает любое изменение в meta-data, делается запись в журнал с описанием предстоящих действий. Только после этого происходит изменение самих метаданных. Таким образом, журналируемая файловая система обслуживает регистрационный файл последних модификаций метаданных. Затраты на ведение такого журнала несравненно ниже, чем сканирование всей файловой системы на предмет непротиворечивости метаданных.
Представьте себе цепочку - хранящиеся данные (stuff), "данные об этих данных" (the data about the stuff) и журнал с meta-meta-data (the data about the data about the stuff).
А что же делает fsck на журналируемой файловой системе? Обычно - ничего. Он просто "не видит" файловую систему и разрешает ее монтирование. Реальное волшебство быстрого восстановления filesystem в непротиворечивое состояние ложится на драйвер файловой системы. Когда файловая система монтируется, Linux filesystem driver выясняет, все ли было в порядке. Если "чистого размонтирования" не было и метаданные должны быть исправлены то, вместо выполнения полного сканирования (как это делает fsck), драйвер читает журнал. Так как в журнале содержится хронология всех последних изменений метаданных, выполняется просмотр мизерной части meta-data. Вопрос о приведении файловой системы в непротиворечивое состояние решается в течение долей, максимум нескольких секунд. В отличие от традиционного (на сегодняшний день) подхода, время восстановления не зависит от размера файловой системы (зависит от интенсивности операций IO в момент, предшествующий краху). Благодаря журналу снимаются многие проблемы, ставшие препятствием на пути увеличения размеров файловых систем.
Теперь перейдем к ReiserFS, первой из нескольких журналируемых файловых систем, которые планируется исследовать. ReiserFS 3.6.x (версия для Linux 2.4) разработана Hans Reiser и его командой Namesys. Hans и его команда проповедуют философию, что лучшая файловая система та, которая формирует единую общедоступную среду, или namespace. В такой среде приложения могут взаимодействовать более гибко, эффективно и мощно. Для достижения этого, файловая система должна выполнять часть работы, традиционно выполнявшуюся приложениями. При таком подходе пользователи часто могут продолжать прямое использование файловой системы вместо формирования уровней специального назначения, типа баз данных и т.п.
Как обстоят дела с размещением в файловой системе большого числа маленьких порций информации? В Namesys решили, по крайней мере, для начала, сосредоточится на одном из аспектов работы файловой системы - работе с маленькими файлами. Строго говоря, файловые системы наподобие ext2 и ufs в этой области ведут себя неэффективно, часто вынуждая разработчиков проектировать базы данных или использовать другие "фокусы" для получения удовлетворительной производительности. Такой подход приводит к "изобретению множества велосипедов" и порождает огромное число несовместимых API узкоспециального назначения.
Разберемся, а за счет чего ext2 поощряет этот вид "велосипедного" программирования. Ext2 хороша для хранения достаточно большого числа файлов размером более двадцати килобайт каждый, но совсем не идеальна для хранения 2,000 50-байтовых файлов. Мало того, что заметно снижается производительность, но и само хранение маленьких файлов на ext2 приводит к неэффективному использованию дискового пространства, так как ext2 ассигнует под каждый файл целое число 1-2-4 KB блоков (размер блока устанавливается при формировании файловой системы).
Обычная житейская мудрость подсказывает нам отказаться от хранения многих смехотворно маленьких файлов непосредственно на файловой системе. Вместо этого возникает идея хранения информации в некоторой базе данных, работающей над filesystem. В ответ на это Hans Reiser сказал бы, что всякий раз, когда формируется уровень над filesystem, это свидетельствует лишь о том, что файловая система не отвечает нашим потребностям. Если бы она удовлетворяла, от этого можно было бы отказаться. Следовательно, хорошо спроектированная файловая система экономит время на разработку и устраняет ни с чем более не совместимый код.
Но это все теория. А как на практике ReiserFS работает с большим числом маленьких файлов? Удивительно, но очень хорошо. Фактически, ReiserFS при обработке файлов размером меньше одного K выигрывает в скорости у ext2 в восемь - пятнадцать раз! Вообще, ReiserFS превосходит по быстродействию ext2 в почти каждой области, но действительно сияет, когда сравнивается обработка маленьких файлов.
За счет чего ReiserFS эффективно работает с маленькими файлами? ReiserFS использует специально оптимизированные b* balanced tree (одно на filesystem) для организации всех данных файловой системы. Одно это дает большое увеличение производительности, а также снимает ряд искусственных ограничений на размещение файловой системы. Например, становится возможным иметь каталог, содержащий 100,000 других подкаталогов. Еще одна выгода от использования b*tree в том, что ReiserFS, подобно большинству других filesystems нового поколения, динамически ассигнует inodes вместо их статического набора, образующегося при создании "традиционной" файловой системы. Это дает большую гибкость и оптимальность в формировании пространства хранения.
ReiserFS также имеет ряд features, нацеленных специально для улучшения работы с маленькими файлами. ReiserFS не связана ограничением в ассигновании памяти для файла в целом числе 1-2-4 KB блоков. По необходимости для файла может ассигноваться точный размер. ReiserFS также включает некоторые виды специальной оптимизации файловых "хвостов" для хранения конечных частей файлов, меньших, чем блок filesystem. Для увеличения скорости, ReiserFS способен хранить содержимое файлов непосредственно внутри b*tree, а не в виде указателя на дисковый блок (в ext2 есть понятие fastlink, когда содержимое "мягкой" ссылки до 60 байт хранится в inode).
Тем самым достигается две вещи. Первое, сильно увеличивается производительность, так как data и stat_data (inode) информация может хранится рядом и считываться одной дисковой операцией IO. Второе, ReiserFS способен упаковать хвосты, экономя дисковое пространство. Фактически, при разрешении ReiserFS выполнять упаковку хвостов (значение по умолчанию) будет экономиться примерно шесть процентов дискового пространства (в сравнении с ext2).
Следует иметь в виду, что упаковка хвостов требует дополнительной работы, так как при изменении размеров файлов необходима "переупаковка". По этой причине в ReiserFS упаковка хвоста может отключаться, позволяя администратору выбрать между скоростью и эффективностью использования дискового пространства.
ReiserFS - превосходная filesystem. В следующей статье будет описан процесс инсталляции ReiserFS под Linux 2.4. Будет описана процедура оптимальной настройки под требования приложений, опции ядра и другое.
Daniel Robbins (drobbins@gentoo.org)
President/CEO,
Gentoo Technologies, Inc.
August 2001
С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. Daniel Robbins отвечает на эти вопросы по ходу пояснения инсталляции этих новых продвинутых filesystems под Linux 2.4. В своей предыдущей статье этой серии Daniel описал преимущества journalling и ReiserFS. В этой статье речь пойдет о процессе инсталляции rock-solid Linux 2.4-based ReiserFS системы.
В этой статье я опишу процесс установки ReiserFS с ядром 2.4. Одновременно будут затронуты "технические" аспекты, касающиеся ядра 2.4 и его сопряженности с ReiserFS, вопросы производительности и т.п. Так как инсталляция будет описана в начале, я рекомендую прежде прочесть всю статью, и лишь потом перейти к практике. Полезно сразу ознакомиться с техническими примечаниями, поскольку при установке ReiserFS на вашу систему такое знание поможет снять ряд вопросов.
Чтобы enable ReiserFS на вашей системе, сначала потребуется найти подходящее ядро. Если вы следите за развитием ядер серии 2.4, то, наверное, знаете, что не все происходит гладко. При написании статьи последним было 2.4.6-pre2. Однако я рекомендую обратить внимание либо на 2.4.4 (a stock Linus kernel), либо на 2.4.4-ac9 (модифицированное ядро от Alan Cox) для установки ReiserFS. Тесты показали, что на 2.4.5 имеются "моменты", которые не позволяют рекомендовать это ядро для промышленного использования. Давайте надеяться, что 2.4.6 в этом плане будет лучше.
Если не хотите использовать 2.4.4 или 2.4.4-ac9 ядро для ReiserFS, прежде убедитесь, что проведены достаточные тесты по исследованию устойчивости ReiserFS на выбранном ядре. Конечно, предупреждение не распространяется для ReiserFS на тестовом сервере, где можно использовать любое ядро, если не поступало сообщений о его "проблемности".
Имеются два серьезных основания для повышенного внимания к проблемам стабильности ядра вообще и стабильности ReiserFS в частности. Первое, до сих пор ReiserFS - "экспериментальная" kernel feature и вы не должны прогнозировать, что ее реализация на более новом ядре будет работать не хуже, чем на предыдущем. Второе (в данный момент это самая большая проблема), большая часть релизов ядра 2.4 и patches были немного flaky side, что предполагает большую осторожность. Теоретически, все 2.4 релизы принадлежат stable series, так как 2.4 "по определению" считается таковой. На практике в этом возникают сомнения.
Я надеюсь, что не отговорил вас от использования ReiserFS или Linux 2.4, но предупреждение не будет лишним. Не прыгайте с одного ядра на другое только по причине его "современности". На промышленных системах такая практика ничего хорошего не сулит. Когда переходите на непроверенное ядро, вы рискуете не только зависанием системы, но и сохранностью данных. Даже если сама ReiserFS устойчива, есть вероятность, что ошибки в других частях ядра приведут к повреждению информации на файловой системе.
Если вы еще не выбрали хороший источник информации по стабильности современных ядер, я рекомендую посетить Linux Weekly News (смотри Resources ниже), чтобы быть "в курсе" kernel problems (информация обновляется каждый четверг). Теперь, когда я убедил читателей в использовании 2.4.4 или 2.4.4-ac9 для ответственных инсталляций ReiserFS, продолжим.
OK, возможны три варианта получения production-ready ReiserFS. Первый, использование простого stock 2.4.4 Linux kernel. Второй, использование 2.4.4 kernel с наложением ReiserFS bigpatch. Он, в свою очередь, содержит специальные patches для придания ReiserFS свойств quota-compatible и дополнительной совместимости с locally-running NFS сервером. Третий, использование 2.4.4 ядра с ac9 patch (что дает нам 2.4.4-ac9) как с bigpatch, так и без него. Я рекомендую использовать 2.4.4-ac9 с bigpatch, так как bigpatch не имеет отрицательных эффектов, а с ac9 ядро работает лучше. Однако, если вы испытываете неприязнь к ac ядрам, используйте простое 2.4.4. Далее описывается процесс установки 2.4.4-ac9 с bigpatch, но если у вас одна или обе patches не установлены, просто пропустите соответствующий шаг. Теперь начнем.
Получите 2.4.4 kernel sources от kernel.org и положите в /usr/src каталог. Переименуйте существовавший linux каталог или symlink на него, либо просто удалите старую symlink. Далее:
# cd /usr/src
# cat /path/to/linx-2.4.4.tar.bz2 | bzip2 -d | tar xvf -
Можно использовать простое 2.4.4 ядро, в нем все имеется. Однако я рекомендую применить следующие ac и bigpatch patches.
Для apply the ac9 patch, получите Alan Cox ac9 patch из kernel.org и выполните:
# cd /usr/src/linux
# bzip2 -dc /path/to/patch-2.4.4-ac9.bz2 | patch -p1
Наложив такой patch (или оставив все без изменений), получите DiCE и ReiserFS bigpatch. Опять же, этот шаг необязателен, но мною рекомендованный, особенно для NFS сервера и поддержки квот (даже если это вам не нужно, patch не навредит). Для наложения bigpatch выполните:
# cd /usr/src/linux
# bzip2 -dc /path/to/bigpatch-2.4.4.diff.bz2 | patch -p1
Выполнив один, оба или ни одного шага, вы готовы к конфигурированию ядра для ReiserFS.
Обратите внимание: если вам требуется помощь в компиляции ядра, есть хорошая, свободно распространяемая обучающая программа Compiling the Linux kernel на developerWorks. Далее очень кратко.
Kernel configuration весьма проста. Сначала выполняем "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.
Важно: никогда не удаляйте ваше текущее ядро, не убедившись в работоспособности нового.
До перезагрузки следует инсталлировать "reiserfsprogs" tools, которые состоят из "mkreiserfs", "resize_reiserfs" (полезно, если у вас используется LVM) и "fsck.reiserfs". Получить самую последнюю версию "reiserfsprogs" (на момент написания статьи - "3.x.0j") можно от Namesys.com download page. Как только 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
После инсталляции tools можно создавать новые partitions (используя "fdisk" или "cfdisk") либо LVM logical volumes (используя "lvcreate") по необходимости и перезагрузить систему. Когда создается standard partitions его можно маркировать как "Linux native file system" (83).
Создание и монтирование файловой системы.
После перезагрузки вы сможете создать файловую систему ReiserFS на пустом partition следующей командой:
# mkreiserfs /dev/hdxy
В этом примере /dev/hdxy - device node, соответствующий свободному partition. Монтирование аналогично любой другой файловой системе:
# mount /dev/hdxy /mnt/reiser
/dev/hdc1 /home reiserfs defaults 0 0
Начиная с этого момента ваша ReiserFS внешне становится тождественной ext2. Вы быстро забудете об изнурительном "fsck", а данные станут доступны быстрее, особенно из маленьких файлов.
Технические примечания по ReiserFS.
Стабильность файловой системы.
Я использовал 2.4.4 с ReiserFS на промышленном сервере в течение месяца (на cvs.gentoo.org development сервере) без каких либо проблем. 2.4.4 и 2.4.4-ac9 зарекомендовали себя надежными. Сервер сильно загружен операциями IO, так как на нем хранятся cvs архив нашего "dev-wiki", почтовый сервер gentoo.org, списки рассылки и другое.
Хотя ReiserFS превосходит по быстродействию практически во всех типах приложений "файловую классику" ext2, имеется ряд областей, где ReiserFS в настоящее время еще не доработан. Это не жесткие ограничения ReiserFS, а те области, до которых разработчики Namesys не имели время добраться.
Да, это истина. ReiserFS не имеет "dump" и "restore" реализации. Если вы желаете использовать ReiserFS, но вам нравится "dump", придется находить иные пути backing data. В действительности это не так актуально. Ядро 2.4 несовместимо с "dump" и "restore" в принципе (а не только на ReiserFS). Для подробной информации о dump/kernel 2.4 incompatibility читайте Linus Torvalds (смотри Resources), где он говорит, "Dump была глупой программой, во-первых. Оставьте ее в прошлом."
Хотя ReiserFS в общем, имеет преимущество в производительности над ext2, в частностях имеются и слабости. Первая - работа с "разреженными" файлами (например, mailbox). ReiserFS заметно хуже справляется с разреженными файлами, чем ext2. Положение должно изменится, когда разработчики Namesys вернуться к оптимизации этой стороны ReiserFS (предполагается в версии 4 ReiserFS). А сейчас ext2 - лучшее решение для приложений, которые помещают информацию в разреженные файлы.
Вы можете столкнуться с проблемами при написании кода, который делает связанный вызов stat() для большого числа файлов. Одно из приложений, которое имеет проблемы (проявляется только с ReiserFS на ядрах 2.4, но не с 2.2) - mutt mailer (смотри Resources) когда он читает большие maildir-style mailboxes. Очевидно, mutt выполняет вызов stats для каждого почтового файла дважды. Это имеет тенденцию замедления работы. В команде разработчиков ReiserFS об этой специфической проблеме знают и работают над ее устранением (решение будет включено в ReiserFS 4 или раньше).
К счастью, имеется пара простых приемов, которые вы можете использовать для "купирования" проблем производительности. Первый прием - монтирование ReiserFS filesystem с опцией "noatime" (опция монтирования, доступная и для других файловых систем). Вероятно, вы знаете, что системы UNIX делают запись atime (время доступа) для каждого объекта файловой системы и этот атрибут модифицируется при каждом чтении файла. Для большинства случаев штамп atime интереса не представляет (даже не могу привести пример, когда atime требуется для "критических" приложений). По этой причине, ничем не рискуя, от его модификации можно отказаться и получить выигрыш в производительности. Можно даже сказать следующее. Если вам не известно, что штамп atime требуется для конкретного приложения, разместившего файлы на конкретной файловой системе, то вы должны монтировать ее с опцией noatime. Используйте примерно следующую запись в /etc/fstab:
/dev/hdc1 /home reiserfs noatime 0 0
В первой статье о ReiserFS я упомянул, что ReiserFS имеет специфическую feature, называемую "tail packing" (упаковка хвостов). А что в ReiserFS называют "хвостами"? Во-первых, файлы, размер которых меньше, чем блок файловой системы или, во-вторых, "кончики" файлов, которые не заполняют весь блок. В первом случае ReiserFS имеет превосходную производительность по причине умения "запихивать" такие "карликовые" файлы в свои b*tree (первичная организационная структура данных). При этом данные хранятся рядом со stat-data (ReiserFS эквивалент i-node). Во втором случае с производительностью иначе. Хвосты не заполняют полный блок и непроизводительно используют дисковое пространство. Для лучшего использования дискового пространства ReiserFS использует "tail packing". Считается, что такая feature позволяет экономить более 5% в сравнении с ext2.
Не следует думать, что упаковка хвостов больших файлов имеет одни достоинства. Один из недостатков - снижение производительности. Разработчики 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" и перемещение файлов в буферную файловую систему "туда обратно". Помните, после пересоздания файлов (инсталляция нового ядра) они снова окажутся "без хвостов". Есть возможность перемонтирования файловой системы (с новыми опциями) без ее размонтирования (подробно в части 3). Ниже показано, как перемонтировать корневую файловую систему с опцией "notail". Команда будет полезной, если для вас обычная практика - упаковка хвостов, но загрузчик "этого не любит" и требуется "распаковать" вспомогательные файлы:
# mount / -o remount,notail
Если вы используете qmail с ReiserFS, то имеется несколько важных замечаний. Первое - необходимо использовать специальный patch к qmail 1.03 sources. Он требуется для устранения проблемы, которая возникает в связи с несинхронными "link()" и "unlink()" вызовами (с ext2 имеется похожая проблема). Далее, можно посетить Jedi's qmail tuning page, где содержится множество хороших советов о том, как оптимизировать производительность qmail. Наконец, имеется Jedi's ReiserSMTP package. ReiserSMTP содержит GPL plug-in для SMTP части qmail. Такая модернизация от Jedi's (специально для ReiserFS) обеспечит удвоение производительности при обработке входящей почты.
Я нахожу, что ReiserFS очень приятная файловая система и дает выигрыш не только на маленьких, но и на больших файлах по сравнению с ext2. Благодаря ReiserFS разработчикам требуется только 15 секунд для модификации CVS Gentoo Linux, притом, что на ext2 это занимало около 2 минут. ReiserFS делает работу более комфортной и позволяет нашему cvs серверу одновременно обрабатывать большее число IO без потери интерактивности.
Притом, что она уже сегодня производит впечатление, будущее представляется еще более интересным. Hans Reiser имеет очень агрессивный творческий план относительно ReiserFS, включая использование ее как full-fledged high-performance database с полной поддержкой transaction и advanced querying features. Со временем можно ожидать, что ReiserFS станет больше чем "другая высокоэффективная файловая система". Это должно открыть новые возможности и подходы для решения традиционных проблем хранения информации. С Namesys можно связывать и будущее развитие Linux.
Daniel Robbins (drobbins@gentoo.org)
President/CEO, Gentoo Technologies, Inc.
September 2001
С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. В этой статье Daniel дает обзор tmpfs, файловой системы, основанной на VM, и описывает новые, ставшими доступными с переходом на ядро 2.4 возможностями "bind"-mounting abilities.
В предыдущих статьях этой серии я описал преимущества журналирования вообще и файловую систему ReiserFS в частности. Была описана процедура установки rock-solid Linux 2.4-based ReiserFS файловой системы. В данной статье обратим свое внимание на нетривиальную тему. Сначала будет рассмотрена tmpfs, еще известная как virtual memory (VM) filesystem. Tmpfs - вероятно лучшая RAM disk-like система, уже сейчас доступная для Linux через новые свойства ядра 2.4. После начального вступления рассмотрим дополнительные возможности ядра 2.4, называемые "bind mounts", которые добавляют много гибкости в монтировании файловых систем. В следующей статье мы сосредоточимся на devfs, а затем потратим время на более глубокое знакомство с новой ext3 filesystem.
Если от меня потребуют объяснить в одной фразе, что такое tmpfs, я бы сказал -
tmpfs подобие ramdisk, но с "изюминкой". Подобно ramdisk, tmpfs использует
ОПЕРАТИВНУЮ ПАМЯТЬ, но, кроме этого, может использовать swap devices. В то
время как традиционный ramdisk это блочное устройство и перед его
использованием необходимо отформатировать раздел командой mkfs
с опциями,
то файловая система tmpfs - устройство не блочное, готовое к использованию
сразу после монтирования. Такие свойства tmpfs делают ее самой привлекательной
из RAM-based файловых систем, известных на сегодняшний день.
Давайте посмотрим на некоторые наиболее интересные свойства tmpfs. Как было отмечено выше, tmpfs может использовать и RAM, и swap. На первый взгляд, это может показаться не принципиальным, но вспомните, tmpfs еще известна как "virtual memory filesystem". Возможно, вы знаете, что ядро Linux "понимает" ресурс "виртуальная память" именно как единое - целое RAM и swap devices. Подсистема VM ядра ассигнует эти ресурсы другим подсистемам и управляет этими ресурсами behind-the-scenes (прозрачно в фоне). При этом часто без ведома "подсистемы - заказчика" перемещает страницы ОПЕРАТИВНОЙ ПАМЯТИ между swap и vice-versa.
Файловая система tmpfs запрашивает страницы у подсистемы VM для хранения файлов. При этом сама tmpfs не знает, находятся ли эти страницы в swap или в RAM; это - "проблема" VM подсистемы. Иначе, tmpfs filesystem знает лишь то, что она использует виртуальную память.
Теперь о другом интересном свойстве tmpfs filesystem. В отличие от большинства "нормальных" файловых систем (например, ext3, ext2, XFS, JFS, ReiserFS) tmpfs не является "надстройкой" над блочным устройством. Поскольку tmpfs напрямую "встроена" в VM, ее можно монтировать сразу после создания командой:
# mount tmpfs /mnt/tmpfs -t tmpfs
После выполнения команды вы получите новую tmpfs filesystem, смонтированную
в /mnt/tmpfs и готовую к использованию. Обратите внимание, нет потребности в
форматировании командой mkfs tmpfs
; да это и невозможно, такой
команды просто не существует. Сразу после команды mount
файловая
система доступна для использования и имеет тип tmpfs
. Это в
принципе отличается от Linux ramdisks; стандартный Linux ramdisks -
block devices и требует форматирования перед размещением на нем файлов.
Что имеем? Монтируй и используй!
Вы вероятно уже задавались вопросом, а какого размера файловую систему мы подмонтировали к /mnt/tmpfs в примере выше? Ответ неожиданный (особенно, если имели дело только с disk-based файловыми системами). /mnt/tmpfs первоначально имеет очень маленький размер, но, по мере копирования и создания файлов драйвер tmpfs ассигнует у VM дополнительную память, динамически увеличивая емкость. Справедливо и обратное, при удалении файлов из /mnt/tmpfs драйвер отдает освобождаемую память операционной системе. Теперь ясно (память достаточно ценный ресурс и ее "никогда не бывает много"), большой плюс tmpfs в том, что используется ровно столько памяти, сколько требуется. См. Resources.
Другое преимущество tmpfs - ее "блестящая" скорость. Поскольку файловая система tmpfs постоянно загружена в оперативную память, операции записи - чтения происходят почти мгновенно. Даже если интенсивно используется swap, скорость все равно высокая (более того, перемещение в swap означает передачу ресурсов процессам, наиболее нуждающимся в памяти, что способствует повышению общей производительности). Итог - свойство динамически изменять размер и, при необходимости, сбрасываться в swap, дает возможность операционной системе более гибко распоряжаться ресурсами. Файловая система tmpfs прекрасная альтернатива традиционному RAM disk с позиции скорости.
А вот это может считаться как плюсом, так и минусом. Как можно догадаться, данные в tmpfs после перезагрузки будут потеряны (оперативная память энергозависима по своей природе. Даже после "горячей перезагрузки", сохранившись в "физической оперативной памяти", информация станет недоступной, так как таблицы виртуальной памяти будут инициализированы иначе). Название "tmpfs" само за себя говорит. Плохо ли это? С какой стороны посмотреть. Фактически, tmpfs превосходный резервуар для хранения временных файлов. Традиционно для этих целей используется /tmp и некоторые части дерева /var. Есть даже опция - очищать /tmp при перезагрузке, на что тратится дополнительное время. В случае с 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 динамически растет и уменьшается. Поэтому естественен провокационный вопрос. А что случится, если 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) очень сложно.
К счастью, tmpfs позволяет указать максимальный размер filesystem при ее
монтировании или перемонтировании. Фактически, с ядром 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 filesystem с лимитом на максимальный размер достаточно просто. Например:
# mount tmpfs /dev/shm -t tmpfs -o size=32m
В этом примере монтирование новой tmpfs происходит не к точке /mnt/tmpfs, а к специально созданному /dev/shm. Это каталог, который является "official" mountpoint для tmpfs. Если вы используете devfs, этот каталог будет создан автоматически.
Если требуется ограничить размер filesystem 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
Монтирование поверх занятой mountpoints
При использовании ядер 2.2 любая попытка монтирования к уже используемой mountpoint приводила к ошибке. После переписи кода ядра повторное монтирование к занятой точке перестало быть проблемой. Такой пример: при загрузке системы монтируется "реальный" раздел диска к точке /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 filesystem монтируется к /tmp поверх ранее смонтированного partition. При этом все новые файлы будут открываться на tmpfs, а процессы, которые имели открытые файлы на "оригинальной" filesystem, так и будут продолжать работать с ними! Если размонтировать tmpfs-based /tmp, "оригинальная" /tmp появится, как и прежде. Фактически, можно монтировать любое число файловых систем на одну mountpoint, и mountpoint будет действовать подобно стеку.
Используя bind mount, мы можем монтировать всю или только часть уже смонтированной filesystem к другой точке и иметь filesystem, доступную от обеих mountpoints одновременно! Например, можно использовать bind mounts для монтирования root filesystem к /home/drobbins/nifty:
# mount --bind / /home/drobbins/nifty
Теперь, если зайти в /home/drobbins/nifty, вы увидите вашу root filesystem (/home/drobbins/nifty/etc, /home/drobbins/nifty/opt и т.д.). Если модифицируется файл на root filesystem, все изменения будут видны и в /home/drobbins/nifty. Так происходит потому, что это одни и те же разделы диска, просто ядро отображает filesystem в двух разных mountpoints. Обратите внимание, когда происходит монтирование файловой системы к новой точке через bind-mounted, все файловые системы, которые были примонтированы к "оригинальной", в новой позиции отображены не будут. Другими словами, если /usr создан на отдельном partition, после выполнения bind-mounted подкаталог /home/drobbins/nifty/usr окажется пустым. Потребуется дополнительное bind mount, чтобы просмотреть содержимое /usr в /home/drobbins/nifty/usr:
# mount --bind /usr /home/drobbins/nifty/usr
Bind mounting для части файловой системы.
Bind mounting делает возможными еще более "тонкие" вещи. Например, вы монтируете tmpfs к /dev/shm, его "традиционной" точке, но одновременно хотите использовать tmpfs для /tmp. Вместо монтирования еще одной tmpfs к /tmp (что возможно), вы решаете share новый /tmp с /dev/shm. Но, bind mount /dev/shm к /tmp нужно сделать так, чтобы каталоги из /dev/shm не были видны в /tmp. Как это сделать? Пример:
# mkdir /dev/shm/tmp
# chmod 1777 /dev/shm/tmp
# mount --bind /dev/shm/tmp /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 server после перезагрузки "грохнется на старте". Второй момент - "аномальное"
наследование при монтировании. Родительский каталог (точка монтирования /tmp)
наследует свойства от дочернего каталога (/dev/shm/tmp). "Не логично",
и "по незнанию" может стать причиной проблем.
Как следует из примера, bind mounts очень сильное средство и может помочь в проектировании файловой системы сложной архитектуры. Следующая статья будет посвящена devfs; а пока можно посмотреть следующие ресурсы.
mount
and umount
. You may want to upgrade to the
latest available version so that you can use the mount --bind
syntax
(rather than using mount -o bind
).
Residing in Albuquerque, New Mexico, Daniel Robbins is the President/CEO of Gentoo Technologies,
Inc., the creator of Gentoo Linux, an advanced Linux for the
PC, and the Portage system, a next-generation ports system for Linux.
He has also served as a contributing author for the Macmillan books
Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed.
Daniel has been involved with computers in some fashion since the
second grade, when he was first exposed to the Logo programming
language as well as a potentially dangerous dose of Pac Man. This
probably explains why he has since served as a Lead Graphic Artist at
SONY Electronic Publishing/Psygnosis. Daniel enjoys spending
time with his wife, Mary, and his new baby daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.
Перевод: Владимир Холманов
Daniel Robbins (drobbins@gentoo.org)
President/CEO,
Gentoo Technologies, Inc.
September 2001
С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. В этой статье Daniel объясняет назначение и преимущества использования devfs, файловой системы управления устройствами и подготавливает к пониманию своей следующей статьи, где будет рассказано об оптимальной установке devfs на вашей системе.
Устройства, устройства повсюду.
Devfs, или Device Filesystem, разработана с единственной целью предоставления нового (более "нормального") способа управления всеми блочными и символьными устройствами, заполнившими каталог /dev. Вероятно, вам известно, что обычное /dev дерево содержит сотни блочных и символьных специальных файлов-устройств, которые располагаются на корневой файловой системе. Каждый такой специальный файл доступен для user-space процессов и обеспечивает легкость взаимодействия с kernel devices. Выполняя операции с такими специальными файлами, X server способен обращаться к video hardware, fsck способен выполнять filesystem checks, а lpd передает данные через параллельный порт на принтер и т.д.
Фактически, одна из "приятных" черт Linux и Unix заключается в том, что devices
не скрыты за некоторым непонятным и специфическим API, а сосуществуют на
файловой системе рядом с "нормальными" файлами, каталогами и символическими
ссылками. Поскольку символьные и блочные devices отображаются в привычное
filesystem namespace, имеется дополнительная возможность более простого
взаимодействия с hardware через стандартные Unix команды, например
cat
или dd
. И это не просто фокус. "Стандартное"
взаимодействие более выразительно и способствует быстрому освоению нового
оборудования.
В то время как сама идея отображения устройств как специальных файлов хороша, следует заметить, что обычные Linux системы управляют ими далеко не оптимальным и громоздким способом. В наши дни в Linux поддерживается много самого разного hardware. При "классическом" подходе это означает, что в каталоге /dev "обитают" сотни специальных файлов для "презентации" соответствующих hardware. Большинство таких специальных файлов "don't even map" на реально существующее на вашей машине устройство (но в каталоге /dev такой специальный файл все равно должен присутствовать на случай добавления нового hardware/drivers). Такой подход вносит много путаницы.
Только одного такого аргумента достаточно, чтобы осознать необходимость "перестройки" каталога /dev, конечно, при соблюдении принципа "обратной совместимости". Чтобы хорошо понять, как именно devfs решает большинство проблем связанных с "классическим" каталогом /dev, посмотрим на devfs с позиции разработки нового драйвера для устройства.
Внутренняя организация device management
Чтобы получить ясное представление о devfs, давайте разберемся, как devfs
меняет традиционный подход для случая добавления нового драйвера. Традиционный
(без devfs) kernel-based device driver "прописывает" устройство в остальной
части системы через системные вызовы register_blkdev()
или
register_chrdev()
(зависит от того, регистрируется блочное или
символьное устройство).
Major номер (unsigned 8-bit integer) передается как параметр либо
register_blkdev()
, либо register_chrdev()
. После
регистрации устройства ядро знает, что этот конкретный major номер соответствует
конкретному драйверу для устройства, которое выполнило вызов
register_???dev()
.
Вопрос, а какой major номер разработчик драйвера должен использовать для
передачи с запросом register_???dev()
? Проблемы нет, если developer
драйвера не планирует его использования "внешним миром". В этом случае сгодится
любой major номер, лишь бы он не конфликтовал с другими major номерами,
используемыми в конкретном частном случае. Как альтернатива, разработчик может
"динамически" ассигновать major номер перед register_???dev()
.
Однако, "по большому счету", такое решение приемлемо только в случае, если
драйвер не предназначен для широкого использования.
Если developer хочет предложить свой драйвер для широкого использования (а большинство Linux developers имеет тенденцию делать именно так), то использование major номера "от балды" или даже вариант с его динамическим ассигнованием "не пройдет". В таких случаях разработчик драйвера должен войти в контакт с Linux kernel developers и получить для своего специфического устройства "официальный" major номер. После этого, для всех Linux пользователей это устройство (и только оно) будет связано с таким major номером.
Важно иметь "официальный" major номер, так как для взаимодействия с этим специфическим устройством, администратор должен в каталоге /dev создать специальный файл. Когда device node (специальный файл) создается, он должен получить тот же major, как зарегистрирован во внутренних структурах ядра. После этого, когда пользовательский процесс выполняет операцию над файлом-устройством, ядро знает, с каким драйвером нужно связаться. Иначе, mapping от специального файла на kernel driver сделано по major номером, а не по именам устройств. Такое "непонимание" device name - особенность non-devfs систем.
Как только device driver получает официальный major, он может использоваться
публично, а device node можно включать в дерево /dev разных дистрибутивов
через официальный сценарий /dev/MAKEDEV
. Такой сценарий помогает
суперпользователю автоматизировать процесс создания device nodes с правильными
major и minor номерами, правами и владельцами.
К сожалению, при таком подходе имеется много проблем. У разработчика драйвера появляется "головная боль" от необходимости согласования действий с kernel developers для получения "официального" major. То же относится к самим kernel developers. Возникает потребность отслеживания процедуры ассигнования всех major номеров. Во многом это похоже на проблемы системного администратора при использовании статического ассигнования IP адресов в локальной сети, когда сеть начинает "разрастаться". Точно так же, как системный администратор может "разрубить узел", воспользовавшись DHCP, можно было бы использовать подобный подход для регистрации devices.
Проблема не только в этом. Linux подошел к границе, когда все "официальные" major и minor номера будут исчерпаны. Конечно, можно просто увеличить разрядность номеров, но при этом станет еще сложнее отслеживать уникальность major для драйверов. Имеется и более радикальный способ решения проблемы. Это переход на devfs.
Подход devfs.
devfs_register()
Имеется быстрое описание того, как devfs функционирует и снимает многие
проблемы. После правильного конфигурирования devfs, что подразумевает
добавление поддержки devfs в ядро и выполнение множества достаточно хитрых
изменений в сценариях запуска, суперпользователь перезагружает систему.
Стартует ядро и device drivers начинают регистрировать свои устройства для
остальной части системы. Если это non-devfs система, как и ранее, выполняются
системные вызовы register_blkdev()
и register_chrdev()
(вместе с сопровождающими вызовы major номерами). Однако, если enabled devfs,
то device drivers для регистрации своих устройств используют новый, улучшенный
kernel call, называемый devfs_register()
.
Об этом devfs_register()
вызове можно много рассказать. Хотя можно
указать major и minor номера для обратной совместимости, жесткого требования,
делать именно так, не существует. Вместо этого вызов devfs_register()
передает path на устройство как параметр, и именно так оно впоследствии
появиться под /dev. Например, драйвер устройства foo регистрирует свое
устройство в devfs. При этом драйвер передает параметр foo0 с вызовом
devfs_register()
, сообщая ядру, что в корне devfs namespace
должен быть создан новый файл-устройство foo0. В ответ на вызов
devfs_register()
добавляется foo0 device node к корню devfs
namespace и запись о том, что этот новый foo0 node должен отобразится на
foo device driver в ядре.
После того, как все device drivers стартовали и зарегистрировали соответствующие
им устройства в ядре, ядро запускает /sbin/init
и начинается
отработка сценариев системной инициализации. На ранней фазе процесса начальной
загрузки (еще до filesystem checks), из rc scripts монтируется devfs filesystem
к точке /dev, которая содержит representation для devfs namespace. После такого
монтирования ко всем зарегистрированным устройствам (например, /dev/foo0)
можно обращаться как на обычной non-devfs системе. Отличие в том, что при
обращении к устройствам, kernel maps на соответствующий device driver
devfs отрабатываются по именам устройств, а не по major номерам.
Красота такого подхода в том, что все требующиеся device nodes (и ничего
лишнего) создаются автоматически ядром. Соответственно, отпадает необходимость
в погоне за последним сценарием MAKEDEV
(так как все
зарегистрированные устройства сами "по волшебству" появляются в /dev). Еще сие
означает, что каталог /dev не загроможден сотнями "фиктивных" device nodes.
Фактически, используя devfs, можно зайти в /dev и узнать, какие устройства у
вас "реально" присутствуют. Например, если у вас laptop с поддержкой "горячей"
замены hardware, то устройства будут появляться и исчезать в /dev по мере того,
как вы вставляете или удаляете PC Cards. Это делает devfs очень "чистым" и
"функциональным" после всего того, что когда-то было.
Devfs делает многие вещи проще. Рассмотрим старт Linux bootable CD-ROM,
который состоит из boot loader, initrd, ядра и loopback filesystem на CD.
Когда BIOS передает управление CD, boot loader грузит ядро и initrd, а затем
стартует /linuxrc
script из "развернувшегося" initrd.
Первоочередная задача /linuxrc
заключается в том, чтобы
смонтировать CD таким образом, чтобы loopback filesystem могла самостоятельно
mounted и accessed.
Без devfs сценарий /linuxrc
должен опробовать множество специальных
файлов в /dev, которые либо "представляют", либо "не представляют" реальное
hardware в системе. Например, /linuxrc
должен просканировать
/dev/hdc, /dev/scd0, /dev/hdb и прочие для обнаружения "живого"
устройства CD-ROM. По мере сканирования будут впустую опробованы несколько
"фиктивных" device nodes.
В том случае, если используется devfs, сценарий /linuxrc
просто
заходит в /dev/cdroms, в котором находятся все специальные файлы,
ассоциированные с "реальными" для данной машины CD-ROM, причем независимо,
IDE или SCSI. Благодаря такому devfs соглашению, выбор очень
конкретный; в подкаталоге перечислены только активные устройства, а
"исследующему коду" даже не требуется знать о подробностях основного CDROM,
например, сидит он на IDE channel или использует SCSI ID. Фактически, это уже
другое достоинство devfs. Как будет видно из следующей статьи этого цикла,
devfs имеет совершенно иные, заданные по умолчанию местоположения для устройств
в /dev.
Если необходимо обратится к конкретному блочному устройству (диск, partition,
CD-ROM и т.д), доступ можно сделать через несколько специальных файлов.
Например, на моем сервере имеется единственный SCSI CD-ROM. При devfs enabled,
я могу работать с ним переместившись либо в /dev/cdroms/cdrom0, либо
в /dev/scsi/host0/bus0/target4/lun0/cd. При этом доступ произойдет к
одному и тому же устройству. Просто у меня есть выбор, через какой именно файл
я это сделаю. Кроме этого, как альтернатива, к своему CD-ROM я могу получить
доступ "в старом стиле" как /dev/sr0, если мне так хочется и
инсталлирована удобная и небольшая программка devfsd
. Версии
devfsd
меняются очень быстро, но, в общем, это программа, которая
заботится об "обратной совместимости" специальных файлов и позволяет
настраивать /dev разными способами. Программа devfsd
будет
рассмотрена в следующей статье при описании процесса перехода на devfs в вашей
системе. А теперь некоторые ресурсы по devfs:
Residing in Albuquerque, New Mexico,
Daniel Robbins is the President/CEO of Gentoo Technologies,
Inc., the creator of Gentoo Linux, an advanced Linux for the
PC, and the Portage system, a next-generation ports system for Linux.
He has also served as a contributing author for the Macmillan books
Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed.
Daniel has been involved with computers in some fashion since the
second grade, when he was first exposed to the Logo programming
language as well as a potentially dangerous dose of Pac Man. This
probably explains why he has since served as a Lead Graphic Artist at
SONY Electronic Publishing/Psygnosis. Daniel enjoys spending
time with his wife, Mary, and his daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.
Перевод: Владимир Холманов
Daniel Robbins (drobbins@gentoo.org)
President/CEO,
Gentoo Technologies, Inc.
October 2001
С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. В этой статье Daniel проведет вас через процесс подготовки системы к использованию devfs. Описание процесса завершается, когда ваша система полностью готова к использованию devfs. И, конечно, предполагается еще одна статья, в которой Daniel опишет заключительную фазу установки devfs.
В предыдущей статье (часть 4) было описание того, чем является devfs и как она решает многие проблемы управления устройствами. Теперь наступило время практической реализации devfs на вашей системе. В этой статье будет описана вся подготовительная работа для devfs-ready, а в следующей - конвертация на devfs. Можно безболезненно выполнить все практические шаги из этой статьи еще до прочтения следующей, так как в результате система будет функционировать "по старому", но в полной готовности к решающему действию.
Обратите внимание: поскольку здесь выполняются достаточно фундаментальные замены частей Linux системы, не исключена возможность возникновения тупиковых ситуаций. Будет хорошей идеей отработать шаги на некритическом Linux box (по крайней мере, в первый раз).
Чтобы иметь работающую devfs требуется Linux 2.4 (статья ориентирована на 2.4.6 или 2.4.8) и glibc 2.1.3 или современней. Рекомендуется Xfree86 не ниже 4.0 и будет не лишним сначала модернизироваться до Xfree86 версии 4.1.
Необходимая предосторожность - освойте bash rescue.
В этой статье предлагается внести изменения в boot-critical части Linux
системы. Любые ошибки, скажем, по обычной невнимательности, в таких вещах могут
приводить к невозможности загрузки системы в "штатном режиме". Я обязан начать
статью с пояснения, как в неприятной ситуации загрузить bash
shell.
Надеюсь, этого не потребуется и все же... Если система не загружается из-за
проблемы в init
scripts или даже непосредственно в
/sbin/init
, повода для волнений еще нет.
Самый простой способ выполнить emergency boot - передать опцию
init=/bin/bash
ядру в паузе boot-time, сделанных GRUB или
LILO. В случае с GRUB вы должны передавать эту опцию, в интерактивном
режиме нажав "e", и редактируя запись menu в реальном времени. В случае
с LILO есть выбор. Можно ввести параметр интерактивно в паузе загрузки или
создать "стационарную" запись для "emergency" в /etc/lilo.conf, не забыв
выполнить lilo.
Процедура "rescue" выглядит так. Сначала передается
init =/bin/bash
ядру в качестве опции начальной загрузки. В
процессе начальной загрузки вместо обычного первого процесса /sbin/init
будет запущен /bin/bash
. Вы увидите bash
root prompt без всякого log in:
#
При этом, несмотря на наличие root bash
prompt, смонтирована
только файловая система root, и та в режиме read-only. От этого пункта двигаемся
дальше. Если файловые системы не размонтированы чисто, требуется сначала
прогнать fsck
. Начните с fsck -a
на root файловой
системе, а затем fsck -R -A -a
на всех остальных:
# fsck -a /dev/hda1
# fsck -R -A -a
Теперь, когда метаданные на ваших файловых системах находятся в непротиворечивом состоянии (либо предыдущий шаг был пропущен вследствие предшествовавшего "чистого размонтирования" или использования журналируемых файловых систем), можно перемонтировать root файловую систему в read-write и монтировать /proc:
# mount / -o remount,rw
# mount /proc
После этого монтируйте остальные требующиеся деревья файловой системы, находящиеся на отдельных partitions. Например, для монтирования /usr:
# mount /usr
Может оказаться полезным активизировать swap, если планируется делать что-нибудь большее, чем запуск текстового редактора. Впрочем, даже использование emacs, может потребовать наличия swap:
# swapon -a
Пришло время запустить любимый редактор и устранить проблему с начальной загрузкой. Повторно перемонтируйте partitions в режим read-only, способом, аналогичным их монтированию. Например, если /usr находится на отдельном partition, то, для приведения файловой системы в непротиворечивое состояние перед перезагрузкой, выполните:
# mount /usr -o remount,ro
# mount / -o remount,ro
Теперь перезагрузка произойдет без запуска fsck
. Если с помощью
редактора вы правильно решили проблему, LILO или GRUB отработают "штатно":
# /sbin/reboot -nfi
Теперь, зная действия при возникновении критической ситуации, можно подготовить
систему к переходу на devfs. В следующей статье будут описаны некоторые
достаточно сложные изменения в Linux системе. Почему это необходимо? Мы сделаем
все, кроме enabling devfs функционирования ядра (последний шаг самый простой).
До этого мы инсталлируем devfsd
(device management daemon)
в специальном режиме так, чтобы он поддержал возможность отката и восстановления
любых изменений в device permissions и ownership. Требуется немного изловчиться,
чтобы получить хорошо функционирующую новую систему. Как только это произойдет,
вы будете очень довольны результатом.
Первый шаг в переходе на devfs достаточно прост: требуется enable devfs support
в ядре. Ядро должно быть серии 2.4. Войдите в каталог с исходниками ядра и
выполните make menuconfig
или make xconfig
(по вкусу).
В секции Code maturity level options проверьте, что Prompt for
development and/or incomplete code/drivers enabled. В секции
File systems находим /dev file system support (EXPERIMENTAL).
Согласитесь с этим пунктом. Откроются еще две дополнительные опции. Первая
указывает, будет ли devfs монтироваться автоматически к /dev в процессе
начальной загрузки. От этого необходимо отказаться, мы будим монтировать /dev
вручную, используя специальный сценарий. Вторая опция, Debug devfs,
также должна быть заблокирована.
Находясь в секции File systems, отключите поддержку /dev/pts file system for Unix98 PTYs, если это еще не заблокировано. Devfs сама обеспечивает подобные функциональные возможности, а devpts в дальнейшем не потребуется. Сохраните конфигурацию, но пока не компилируйте и не инсталлируйте новое ядро. Перед переходом к следующему шагу убедитесь, что при наличии записи о /dev/pts в /etc/fstab она должна быть закомментирована, чтобы впредь, при перезагрузках, больше не монтировалась.
Загрузите в редактор файл /etc/securetty. Этот файл используется
login
и позволяет перечислить allows tty
's, т.е.
разрешенные для входа в систему пользователем root. В нем обычно перечислены
устройства от tty1
до tty12
, по одному на строку.
Чтобы файл подготовить для devfs, необходимо добавить devfs-style имена для
своих tty's, сохранив старые на случай загрузки с devfs disabled. Добавьте
следующие строки после старых записей в /etc/securetty.
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
vc/12
Следующим шагом инсталлируем в системе devfsd
(devfs helper daemon).
Devfsd позаботиться о создании "old-style" compatibility device nodes,
автоматизации действий, связанных с registered/unregistered драйверов,
запоминания изменений в правах и владельцах специальных файлов на файловой
системе root и т.п. В данный момент требуется только сама инсталляция, а в
следующей статье научимся ее использовать вместе с devfs. Загрузим с ftp самую
современную версию devfsd
tarball (см. Resources). На момент написания статьи это была 1.3.16.
Выполним следующее:
# tar xzvf devfsd-1.3.16.tar.gz
# cd devfsd
# make
Devfsd откомпилирован и готов к инсталляции. Если man pages хранятся в
/usr/man, выполните make install
, а если используете
FHS-compliant и man pages находятся в /usr/share/man, то выполните
make mandir=/usr/share/man install
. Devfsd теперь инсталлирован,
но не в рабочем состоянии (именно то, что на данный момент и требуется).
Примечание по конфигурации.
Мы будем конфигурировать |
Теперь пришло время скомпилировать и инсталлировать ядро (которое ранее было сконфигурировано). Это ядро должно подменить ваше текущее. Оно должно загрузиться как обычное, хотя и имеет встроенную поддержку devfs. Вы не должны заметить отличий в их функционировании. После инсталляции убедитесь, что после перезагрузки все работает прекрасно.
Теперь система готова к конвертированию devfs, что является темой следующей статьи. Но, сначала, познакомимся с самим подходом к конвертированию. Как будет показано, devfs-enabling дистрибутив может быть очень хитрым, особенно, если есть желание использовать удобные features, например, persistent permissions и ownership.
Проблемы с kernel automounting
Имеется несколько способов devfs-enable. Первый - иметь ядро с поддержкой
автоматического монтирования devfs к /dev в процессе начальной загрузки
(помните? Мы отказались от этой опции). На первый взгляд, такой подход наиболее
предпочтителен, так как гарантирует, что все devfs-style devices доступны всем
процессам, включая /sbin/init
. Однако при таком подходе имеются
и проблемы. Если devfs обеспечивает все "new-style" devices, то old-style device
nodes создаются devfsd
daemon. Devfsd не запускается ядром, и,
если мы имеем kernel mount devfs at boot, мы окажемся с не
смонтированными device nodes ко времени запуска /sbin/init
. Из
этого следует, что, отработав до system initializations scripts, процесс
загрузки потребует старта devfsd
одним из первых. Хитрость не
только в этом (требуется детальное понимание взаимодействия startup scripts на
конкретной системе). Такой подход порождает другие проблемы.
Основная проблема с kernel mounting состоит в том, что devfsd
оптимизирован для работы, когда он имеет доступ к содержимому "оригинального"
old-style on-disk /dev каталогу. Обычное решение - allow access к "оригинальным"
old-style devices через bind-mounting /dev к другой точке (обычно
/dev-state) до того, как devfs монтируется к /dev.
Такое решение гарантирует, что содержимое старого каталога /dev все еще
доступно в /dev-state после монтирования devfs. При таком подходе
devfsd
может использовать этот каталог для persistent device
storage. Важно понять, что без bind mount старое содержимое /dev становится
недоступным сразу после монтирования devfs к /dev. В этом суть проблемы при
использовании kernel mount devfs. Если ядро монтирует файловую систему
devfs к /dev до старта любого процесса, способного выполнить bind mount, то
содержимое "оригинального" /dev становится полностью недоступным. Неприятность,
не так ли? (О bind mounts было рассказано в части 3
этого цикла.)
В идеале хотелось бы иметь полный набор device nodes (new-style и old-style
для обратной совместимости) еще до старта /sbin/init
, а также
возможность выполнить bind mount /dev к другой точке перед монтированием devfs.
Но возможно ли это?
Одно из возможных решений - добавление специального kernel patch, чтобы
выполнить bind mount от /dev к /dev-state. Но, при таком решении проблемы
загрузки, создаются неудобства, связанные с необходимостью вручную править
исходники каждого нового Linux ядра перед его компиляцией и инсталляцией.
Имеется альтернативный (по мнению автора - лучший) способ решения проблемы
"курица или яйцо" для devfs, через использование init wrapper. Для этого
конкретного случая init wrapper реализован как bash
script,
который "подставляется" вместо /sbin/init
(а реальный init
переименовывается в /sbin/init.system). Коротко о том, что делает
init wrapper:
#!/bin/bash
mkdir -f /dev-state
mount --bind /dev /dev-state
mount -t devfs none /dev
devfsd /dev
exec /sbin/init.system
Первое, wrapper гарантирует, что /dev-state существует. Второе, /dev tree
через bind mount перемонтируется к /dev-state для доступности содержимого /dev
из каталога /dev-state. Третье, монтируется файловая система devfs к вершине
/dev, и, четвертое, стартует devfsd
так, что old-style устройства
автоматически регистрируются одновременно с devfs. Последнее, через команду
exec
стартует "оригинальный" /sbin/init
, который
заблаговременно был переименован в /sbin/init.system
. Команда
exec
осуществляет "обратную подмену" bash
script
на init.system
. Из этого следует, что bash
script
завершается, а его идентификатор (ID 1) наследуется init.system
(идентификатор, требуемый для процесса init). Когда /sbin/init.system
запускается, начальная загрузка системы происходит как обычно за исключением
того, что devfs уже полностью в рабочем состоянии. Использование init wrapper
позволило отказаться от kernel patch или иметь дело с devfs системой,
имеющей ограниченную обратную совместимость (kernel devfs automount).
В следующей статье будет описание процесса получения full версии init wrapper и
примеры использования преимуществ многих мощных devfsd
's features.
About the author![]() Перевод: Владимир Холманов Руководство по "продвинутым" файловым системам, часть 6Первоисточник : http://www-106.ibm.com/developerworks/library/l-fs6.htmlПереход на devfs (с использованием init wrapper)
Daniel Robbins (drobbins@gentoo.org) С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. В этой статье Daniel демонстрирует использование init wrapper и конвертацию системы на использование "devfs mode". Эта статья завершает описание конвертации Linux под использование devfs или Device Filesystem. Для тех, кто только что начал чтение, будут полезны ссылки. В части 4 этой серии статей объяснялось, как devfs решает проблему регистрации устройств на уровне ядра. В части 5 я описал все шаги, необходимые для придания вашей Linux системе свойства devfs-совместимости (без этого переход на devfs невозможен). Если вы не читали часть 5, очень важно сделать это теперь, прежде чем выполнить описанные ниже команды. Если не сделать предварительную подготовку, есть гарантия, что init wrapper, который будет инсталлирован, правильно работать не сможет. В таком случае вы останетесь с системой, которая не может загружаться и требует больших усилий для своей "реанимации". Однако если вы прочли и сделали все, о чем писалось в части 5, можно двигаться дальше. Часть 5 этой серии статей завершилась описанием концепции init wrapper с объяснением, почему именно таким способом удобно решать проблему инициализации devfs. Без углубления в детали, все же по шагам "пройдемся" по полной версии init wrapper и "вникнем" в ее части. Начнем с вершины: The init wrapper, top portion
Как можно заметить, init wrapper - "правильный"
Теперь смотрим ниже. Команда
Ниже - первая условная инструкция,
В случае, когда wrapper запускается ядром при начальной загрузке, сценарий
получает PID равный 1. Первая условная конструкция будет пропущена, а
Если отрабатывается эта часть кода, значит, идет процесс начальной загрузки.
Первое действие - монтирование /proc к файловой системе root, которая все еще
установлена в режиме read-only. После этого следует большой и сложный кусок
Мы воспользуемся преимуществом существования
Перед нами большая условная инструкция, которая выполняется только тогда, когда
переменная devfs установлена в
Однако если выбрана установка devfs, сценарий входит внутрь условного выражения.
В этой инструкции выясняется, была ли devfs уже смонтирована ядром. Делается это
через простой "визуальный" контроль наличия символьного устройства
Если все OK, мы выполняем установку devfs, которая была описана в конце прошлой
статьи. При этом /dev is bind-mounted к /dev-state, а файловая система devfs
монтируется к /dev. Теперь о том, что было пропущено в прошлой статье. Мы
проверяем существование каталога
Что случиться, если в системе используется non-devfs kernel module? Казалось бы,
достаточно создать device node в /dev вручную. Проблема в том, что созданный
вручную new device node будет проигнорирован
Осталось запустить Теперь приступим к инсталляции init wrapper. Сначала напишите исходный wrapper.sh и сохраните его где-нибудь в вашей системе. Сделайте следующее: Installing the init wrapper
Теперь init wrapper на месте.
Используя init wrapper, мы уходим от использования сложного компилированного
initscript. Однако полностью избежать всех проблем нам не удастся. Если не
предпринять дополнительных мер, то
Ключ
Теперь перезагрузка практически подготовлена. Но, прежде, посмотрим на
Загрузите
Каждая из этих четырех строк состоит из event (
Эта запись сообщает Продолжим разбор строк из devfsd.conf: devfsd.conf, continued
В этих нескольких строках предписывается
Следующие три строки включают /dev-state persistence для всех остальных устройств.
Восстановятся любые атрибуты из /dev-state, когда устройство регистрируется
или стартует сам Заканчивается мой devfsd.conf следующими строками: devfsd.conf, end
Эти четыре строки необязательные, но они достойны упоминания. В то время как
/dev-state persistence работает чудесно для device nodes, к символическим
ссылкам это не относится. Возникает вопрос: как обеспечить, чтобы символические
ссылки, например /dev/mouse или /dev/cdrom, не просто существовали, но и
автоматически "воссоздавались" после перезагрузок? В конфигурациях
Перед перезагрузкой можно посмотреть Richard Gooch's devfs FAQ. По этой ссылке можно найти информацию о devfs naming scheme, особенно полезную, когда вы только знакомитесь с именами устройств нового стиля (смотри Resources ниже). Я также рекомендую распечатать на принтере из части 5 порядок действий при "emergency bash rescue", если это для вас новость. Помните, если по каким то причинам init wrapper script создаст проблему, вы всегда можете удалить его следующей последовательностью спасательных команд. Загрузитесь "emergency bash rescue", выполните remounting корневой файловой системы в режим read-write и последовательно сделайте: Откат к статусу pre-wrapper, если необходимо.
Выполнив эти команды, перемонтируйте файловую систему в режим read-only и перезагрузите систему. Система откатится в pre-wrapper state. Исправьте ошибки, снова перезагрузитесь и наслаждайтесь devfs!
About the author![]() Перевод: Владимир Холманов Руководство по "продвинутым" файловым системам, часть 7.Первоисточник : http://www-106.ibm.com/developerworks/library/l-fs7.htmlПрезентация ext3
Daniel Robbins (drobbins@gentoo.org) С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. Daniel Robbins отвечает на эти вопросы по ходу пояснения инсталляции этих новых продвинутых filesystems под Linux 2.4. По большей части статья основана на ext3 - новой улучшенной версии ext2 с возможностями journaling. В прошлых статьях имелся обзор non-traditional filesystems типа tmpfs и devfs. Теперь пришло время вернуться к disk-based filesystems, и это делается на примере ext3. Ext3 filesystem, разработанная Dr. Stephen Tweedie, сформирована на структурах существующей ext2 filesystem; фактически, ext3 очень похожа на ext2 за исключением маленького (но важного) отличия - она поддерживает journaling. После такого "маленького" добавления в ext3 появились некоторые удивительные и интригующие возможности. В этой статье дается сравнение ext3 с другими journaling filesystems, доступными для использования уже сегодня. Планируется выход еще одной статьи об использовании ext3.
Еще одно достоинство ext3 происходит из того, что она основана на коде ext2.
Дисковый формат ext2 и ext3 идентичен; из этого следует, что при необходимости
ext3 filesystem можно монтировать как ext2 без каких либо проблем. И это
еще не все. Благодаря факту, что ext2 и ext3 используют идентичные метаданные,
имеется возможность оперативного обновления ext2 в ext3. Именно так.
Имеется ряд системных утилит, работающих с современными 2.4 ядрами (например,
Если от меня потребуют дать характеристику ext3 в одном слове, я бы сказал - удобная. Это действительно удобно как следствие насколько только возможной совместимости ext3 с существующей ext2. После обновления вам не придется сталкиваться с любыми неожиданностями. Есть еще одна характеристика, положительно отличающая ext3 от остальных journaled filesystems под Linux - высокая надежность, но об этом ниже.
Сначала поясним ситуацию с metadata-only journaling. Например,
вы редактировали файл Однако, в случае такого сбоя имеется высокая вероятность, что в файле
Причина в следующем. "Обычные" journaled filesystems, подобные ReiserFS, XFS и JFS опекают метаданные, но для повышения производительности заботу о данных не проявляют. В нашем примере происходила модификация некоторых filesystem блоков и соответствующих им метаданных, но синхронизация была неожиданно прервана. "Непротиворечивость" файловых блоков будет восстановлена, чего нельзя сказать об их "наполнении".
Имеется два важных момента в JBD-managed ext3 journal, вытекающих из хранения журнала в inode файле (в базовом варианте). Первое, в зависимости от ключей монтирования ext3 filesystem, этот файл можно "видеть" или "не видеть" (расположен в /.journal). Второе, такое хранение журнала делает возможным переход к ext3 через простое добавление единственного файла (и замену драйвера) без использования несовместимых расширений к ext2 метаданным. Это ключ к пониманию "обратной совместимости" ext3 filesystem с ext2 метаданными и "прямой совместимости" ext2 с ext3 драйвером.
JBD использует иной подход. Вместо регистрации промежуточных байтов сохраняются полностью измененные блоки файловой системы. Драйвер Ext3, аналогично, хранит полные точные копии модифицируемых блоков (1КБ, 2КБ или 4КБ) в памяти до завершения операции IO. Это может показаться расточительным. Полные блоки содержат не только изменившиеся данные, но и не модифицированные. Подход, используемый JBD, называется "физическим журналированием", что отражает использование JBD "физических блоков" как основную единицу ведения журнала. Подход, когда хранятся только изменяемые байты, а не целые блоки, называется "логическим журналированием" (используется XFS). Поскольку ext3 использует "физическое журналирование", журнал в ext3 имеет размер больший, чем в XFS. За счет использования в ext3 полных блоков, как драйвером, так и подсистемой журналирования нет сложностей, которые возникают при "логическом журналировании". Кроме того, использование полных блоков позволяет исполнение некоторой дополнительной оптимизации, например "squishing" нескольких ожидающих обработки операции IO в пределах моноблока в одной структуре оперативной памяти. Это позволяет ext3 записывать на диск несколько смежных модификаций одной операцией. Как дополнение, при операциях записи существенно сокращается нагрузка на CPU.
Первоначально ext3 разрабатывалась для журналирования full data и metadata. В этом режиме (называется "data=journal" mode), JBD журналирует все изменения в filesystem, связанные как с data, так и с metadata. При этом JBD может использовать журнал для отката и восстановления metadata и data. Недостаток "полного" журналирования в достаточно низкой производительности и расходе большого объема дискового пространства под журнал. Недавно для ext3 был добавлен новый режим журналирования, который сочетает высокую производительность и гарантию непротиворечивости структуры файловой системы после сбоя (как у "обычных" журналируемых файловых систем). Новый режим работы обслуживает только metadata. Однако драйвер ext3 filesystem по-прежнему отслеживает обработку целых блоков данных (если они связаны с модификацией метаданных), и группирует их в отдельный объект, называемый transaction. Транзакция будет завершена только после записи на диск всех данных. "Побочный" эффект такой "грубой" методики (называемой "data=ordered" mode) - ext3 обеспечивает более высокую вероятность сохранности данных (по сравнению с "продвинутыми" журналируемыми файловыми системами) при гарантии непротиворечивости metadata. При этом происходит журналирование изменений только структуры файловой системы. Ext3 использует этот режим по умолчанию.
Ext3 имеет множество преимуществ. Она разработана для максимальной простоты развертывания. Она основана на годами проверенном коде ext2 и получила "по наследству" замечательный fsck tool. Ext3 в первую очередь предназначена для приложений, не имеющих встроенных возможностей по гарантированию сохранности данных. В целом, ext3 - замечательная файловая система и достойное продолжение ext2. В моей следующей статье будет описана установка и работа с ext3. До этого можете посмотреть некоторые ресурсы.
About the author![]() Перевод: Владимир Холманов Руководство по "продвинутым" файловым системам, часть 8.Первоисточник: http://www-106.ibm.com/developerworks/library/l-fs8.htmlНеожиданности от ext3.
Daniel Robbins (drobbins@gentoo.org) С выходом релиза 2.4 Linux появилась возможность использования filesystem с новыми свойствами, таких как Reiserfs, XFS, GFS и других. Эти filesystems еще не достаточно опробованы и имеются вопросы, что именно они могут делать, насколько они хороши и насколько оправдано их использование в промышленной Linux среде. В этой статье Daniel продолжает рассматривать ext3, новую улучшенную версию файловой системы ext2 с возможностью journaling. В статье вы найдете описание режимов ext3 и демонстрацию некоторых неожиданных ext3 data=journal показателей интерактивной производительности. Я хочу быть честным. В этой статье я планировал описать установку и настройку ext3 на вашей системе. Хотя такая цель была обозначена, это не совсем то, о чем пойдет разговор. У Andrew Morton's имеется превосходная "Using the ext3 filesystem in 2.4 kernels" страница (смотри Resources далее), что делает простое объяснение перехода на ext3-enable излишним (зачем повторять то, что прекрасно описано у других). Вместо этого я собираюсь обратить ваше внимание на неожиданные стороны использования ext3 и, думаю, это будет полезным для вас. После прочтения этой статьи вы будете готовы к более осознанному переходу на ext3, чем в случае "пересказа" Andrew's page. По крайней мере, я на это надеюсь. Давайте начнем с ядра. Я обсуждал стабильную 2.4 ветку, когда описывал ReiserFS. При написании той (часть 2) статьи я рекомендовал остановиться на одной из последних к тому времени 2.4.4-ac9 версии ядра. В то время эту версию можно было рекомендовать как наиболее приемлемую для использования ReiserFS в промышленной среде. Поскольку с того времени утекло много воды и 2.4.4-ac9 уже не новость, пришло время сказать несколько слов о более современных версиях. С появлением 2.4.10 серия 2.4 вышла на новый уровень производительности и универсальности (а вопросы были). Что же такое принципиальное случилось, что позволило Linux 2.4 выйти из кризиса? В акрониме к VM Linus признал, что серия 2.4 не оправдала надежд, и, прежде всего, из-за проблематичного кода VM. Первоначальный код поменяли на неотработанную и среднюю VM реализацию от Andrea Archangeli. Новая VM реализация от Andrea (впервые появилась в 2.4.10) стала действительно большим шагом вперед. Производительность ядра реально увеличилось, а система стала более чувствительной. 2.4.10 определенно поворотный пункт в развитии ядра 2.4 Linux. До этого момента оптимизм понемногу таял, и возникали вопросы, а не примкнуть ли к команде FreeBSD developers. Нужно отдать должное Linus за его решительность к таким серьезным (но необходимым) изменениям в стабильной ветке. После такого поворота событий и включения нового VM кода от Andrea требуется немало времени для "затирания швов" (вопросы стабильности вышли на первый план). Используйте ядра 2.4.13+, а лучше 2.4.16+ (но не между ними) для rock-solid ext3. Код был интегрирован в ядро (без patch) начиная с версии 2.4.15-pre2. Нет оснований избегать использования 2.4.16+ ядра, с ним реализация ext3 будет полной. Когда будете читать Andrew's page (смотри Resources дальше), имейте в виду, начиная с 2.4.16 нет надобности накладывать patch на ядро (это уже сделано). Обратите внимание, я рекомендую использовать 2.4.16+ (даже 2.4.13+), но не 2.4.15+. На это есть серьезные основания. В релизе 2.4.15-pre9 был обнаружен ugly filesystem corruption bug. Выбор 2.4.16+ ядра избавит вас от возможных проблем.
Ext3 имеет твердую репутацию rock-solid filesystem, и я с удивлением узнал, что у нескольких пользователей laptop возникли проблемы при переходе на ext3. Был соблазн, как реакция на подобные сообщения, отказаться от использования ext3. Однако, разбираясь в причинах таких явлений, я обнаружил, что проблемы не связаны непосредственно с ext3, а были вызваны laptop hard drives. Вы можете этого и не знать, но самые современные hard drives имеет нечто, называемое "write cache". Он используется hard drive для сбора ожидающих обработки операций записи. Помещая ожидающие обработку записи в кэш, hard drive firmware может переупорядочивать и группировать их так, чтобы они были записаны на диск самым быстрым из возможных способов. Кэш записи с такой позиции очень полезная вещь (читайте объяснение Линуса и его мнение о write caching в разделе Resources). К сожалению, некоторые laptop hard drives имеют сомнительную возможность игнорирования любого "официального" ATA request с требованием сброса на диск их write cache. Возразить нечего, такая "замечательная" feature до недавнего времени не была запрещена ATA спецификацией. При взаимодействии с такими типами дисков у ядра нет возможности гарантировать, что специфический блок был "фактически" сброшен на диск. Хотя это необходимая причина вдруг возникшей проблемы с нарушением целостности данных, но еще не достаточная. Ситуация оказалась еще хуже. Некоторые современные laptop hard drives имеют еще более "вредную" привычку без команды сбрасывать свой write cache, когда система перезагружается или "засыпает". Если hard drive наделен обеими features, а файловая система поддерживает журнализацию, происходит периодическое разрушение данных и нельзя ничего предпринять для предотвращения этого. Где решение? Если вы имеете laptop, действуйте осторожно. Сохраните важные файлы перед внесением больших изменений в файловую систему. Если возникнут проблемы с нарушением целостности данных после перехода на ext3, возможно причина в "продвинутости" вашего диска. В таком случае можно войти в контакт с изготовителем вашего laptop hard drive по вопросу о его замене. Есть надежда, что уже в ближайшее время эти диски уйдут с рынка (или переместятся на рынки третьих стран - прим. переводчика) и о проблеме можно будет забыть. Теперь, после испуга, вы готовы к обсуждению различных ext3 опций journaling данных.
Ext3 предлагает на выбор три режима journaling при монтировании файловой системы:
Для указания journal mode можно добавить соответствующую строку (например,
В режиме
В режиме
Что касается гарантии от разрушения данных. При добавлении данных в конец файла
режим
Режим
Теоретически, режим
Одновременно с записью данных на тестируемую файловую систему, он попытался прочесть 16Mb данных с другой ext2 файловой системы того же диска, подсчитав результаты: Чтение 16Mb файла.
Результат оказался поразительным. Режим data=ordered
93
| ||
Общая тема : Руководство по "продвинутым" файловым системам, часть 9 |
Первоисточник : http://www-106.ibm.com/developerworks/library/l-fs9.html |
About the author![]() |
Перевод: Vladimir Kholmanov