Многообразие Linux стало притчей во языцех, что одновременно усложнило процедуру установки этой операционной системы. Традиционно дистрибутивы Linux разделялись на несколько линий. Представители этих линий различаются подходом к процессу установки, логикой иерархии файловой системы, программами управления пакетами и их форматом, организацией запуска стартовых служб и т.п.
Многообразие Linux стало притчей во языцех, что одновременно усложнило процедуру установки этой операционной системы. Традиционно дистрибутивы Linux разделялись на несколько линий. Представители этих линий различаются подходом к процессу установки, логикой иерархии файловой системы, программами управления пакетами и их форматом, организацией запуска стартовых служб и т.п.Однако роднит их одно — все дистрибутивы пакетные и образованы путем компиляции наборов, включающих ядро, средства загрузки, системные и пользовательские утилиты и прикладное ПО. В то же время, все более активно развиваются дистрибутивы, основанные на сборке из исходных текстов (Source Based Distributions — SB-дистрибутивы, http://distrowatch.com) и предусматривающие установку из скомпилированных пакетов только базовых компонентов системы — все пользовательские приложения собираются непосредственно из авторских исходных кодов.
SB-дистрибутивы обеспечивают большую гибкость установки и обновления, практически неограниченные возможности оптимизации под конкретную машину или задачу. Взамен этого SB-дистрибутивы предъявляют более высокие, нежели при пакетной установке, требования к квалификации пользователя. Конечно, прекрасная документированность SB-дистрибутивов делает процесс их установки доступным не только для Unix-гуру, однако от пользователя требуется понимание ключевых этапов установки: создание дисковых разделов; файловых систем и монтирование.
С процедуры подготовки диска начинало знакомство с ОС не одно поколение грядущих ее пользователей, а устрашающие комментарии к ней были непременным атрибутом описания процесса подготовки к инсталляции. Потом пришло время графических инсталляторов и специализированных утилит для управления разделами, начиная с Disk Druid из Red Hat и заканчивая дисковыми менеджерами Caldera, Mandrake, ASPLinux. Казалось бы, пользователю Linux, особенно начинающему, жить стало лучше и проблема дисковых разделов уже не выглядит столь пугающей. Так почему же возникает необходимость снова обратиться к ней? Во-первых, эпоха, когда Linux можно было без проблем установить на диск в 300-500 Мбайт, канула в Лету — ныне ни один уважающий себя дистрибутив не запросит менее 1-1,5 Гбайт. Иными стали и требования к структуре разделов, мало кого удовлетворит элементарная схема из root- и swap-разделов. Да и файловые системы стали иными — к единственной еще недавно ext2fs добавились разнообразные журналируемые системы и программные RAID-массивы, особенности которых приходится учитывать уже на стадии разбиения диска. Во-вторых, никакие менеджеры дисков не заменят понимания логики создания разделов, которая если и не гарантирует полностью от ошибок, то хотя бы сведет к минимуму их вероятность.
Создание дисковых разделов
Всякий, кто хоть раз устанавливал эту ОС Linux знает, что ATA-диски (SCSI-накопители — тема особая и для большинства пользователей все менее актуальная) в Linux маркируются в соответствии с порядком подключения к IDE-контроллеру: первый диск на первом канале — /dev/hda, второй — /dev/hdb, третий — /dev/hdc, четвертый — /dev/hdd. Эти имена дисков (собственно, не дисков, а файлов соответствующих им устройств) всегда неизменны.
Разделы на дисках маркируются дополнительными цифрами: с hd?1 по hd?4 для первичных разделов и начиная с hd?5 — для логических томов расширенного раздела. Поскольку в Linux принята таблица разделов в стиле MS DOS, последний может присутствовать только в единственном экземпляре, отнимая одно поле в таблице у разделов первичных. На физическом диске теоретически могут сосуществовать три первичных раздела и некоторое количество логических томов, например, hda1-hda3 и hda5-hda8. Ныне это нуждается в коррективах — большинство современных дистрибутивов Linux на базе ядра 2.4.xx задействуют файловую систему devfs, которая предоставляет массу дополнительных возможностей, в частности, избавляет от резервирования имен для отсутствующих в системе устройств, проблем со старшими номерами устройств и многого другого. Однако в ней по умолчанию применяется совершенно иная номенклатура и предусмотрены совершенно иные места для размещения файлов устройств. Так, для файлов любых ATA-накопителей предназначен каталог /dev/ide (в некоторых дистрибутивах файловая система устройств монтируется в каталог /devices, а каталог /dev сохраняется для совместимости). Файлы накопителей на встроенном IDE-контроллере локализуются в подкаталоге /dev/ide/host0. А внутри него есть два подкаталога, соответствующие IDE-каналам — /dev/ide/host/bus0(bus1), каждый из которых опять же может делиться надвое: на каталоги target0 и target1, по количеству подключенных устройств. Внутри каталога target0(1) имеется минимум еще один подкаталог lun0. А уж в нем размещаются непосредственно файлы устройств: disc для всего накопителя, part1, ... part# для разделов. Таким образом, полное обозначение дискового раздела будет выглядеть как:
/dev/ide/host0/bus0 /target0/lun0/part1
для первого первичного раздела на первом диске первого IDE-канала. Предусмотрен и более краткий способ обращения к файлам устройств — через жесткие ссылки (иные имена для тех же наборов данных). Для файлов дисковых накопителей они собраны в каталоге /dev/discs (для файлов CD-приводов, например, в каталоге /dev/cdrom) с подкаталогами disc0, ... , disc#. И потому к приведенному в качестве примера разделу можно обратиться и так:
/dev/discs/disc0/part1
Наконец, для совместимости со старыми соглашениями в большинстве дистрибутивов поддерживается номенклатура, принятая до внедрения devfs — все то же из примера можно обозвать просто как /dev/hda1.
Таким образом, подключение devfs не препятствует использованию старой номенклатуры накопителей. Которая и будет использоваться далее в примерах. Однако нужно помнить, что это лишь трансляция истинных имен файлов устройств, к которым и следует обращаться, если что-то не сработает.
При использовании файловой системы devfs имена файлов создаются только для реально существующих в системе устройств. Поэтому, если в системе имеется только единственное IDE-устройство, скажем, жесткий диск как мастер на первом канале, бесполезно было бы искать файлы устройств с именами, отличными от приведенного в примере — это удобно, но при неаккуратной реализации devfs может создавать сложности. Так, мне встречались дистрибутивы, в которых без дополнительных настроек удавалось смонтировать IDE-Zip только в том случае, если он находился в приводе в момент старта системы.
Чем разбивать?
На данный момент в мире свободного ПО используется три основные программы разбиения диска: традиционный fdisk, его собрат cfdisk, считающийся более дружелюбным к пользователю и относительно новая GNU-утилита parted. Кроме того, существуют и «продвинутые» дисковые менеджеры типа Disk Druid или HardDrake, однако о них речи здесь не будет. Как и о таких широко известных программах, как Partition Magic или отечественный продукт Acronis OS Selector. Несмотря на их многочисленные достоинства, они не являются открытыми.
Именно fdisk больше всего пугал в старые времена начинающих пользователей Unix, хотя ничего устрашающего в нем нет — просто «fdisk /dev/hd?», где в качестве имени устройства фигурирует физический диск, например, для мастера на первом канале это будет /dev/hda. При использовании devfs (и отказе от опознания файла устройства в старой номенклатуре) можно прибегнуть к форме
fdisk /dev/discs/disc#/disc
или к указанию полного имени файла устройства. Благодаря прекрасной системе помощи в любой момент можно получить полный список доступных команд, а команда p выведет текущее состояние разделов на диске. Разделы эти можно создавать (командой n) или удалять (командой d), однако до команды записи изменений (w) никаких необратимых действий, способных разрушить ранее существующие файловые системы (например, FATxx) не последует: неудачно созданные разделы можно удалить и на их месте создать новые.
При создании раздела средствами fdisk сначала определяется, будет ли он первичным (primary) или расширенным (extended), т. е. тем контейнером, в котором в дальнейшем будут созданы логические тома). Далее указывается номер раздела (от 1 до 4 для первичных и от 5 и выше — для логических). В этих пределах номер может быть любым — можно сначала создать раздел 2, а потом 1, или даже весь диск отвести под раздел 4 (именно так размечены фабричным способом zip-диски, почему соответствующие им файлы устройств в старой нотации выглядят как /dev/hd?4). Номер раздела останется на века: именно он будет идентифицировать файл устройства, соответствующий созданному разделу (например, /dev/hda2, или /dev/discs/disc1/part2).
Далее задается начальный цилиндр создаваемого раздела (по умолчанию — первый свободный, а для пустого диска — просто первый. Однако никто не мешает указать любой другой цилиндр в качестве стартового). А потом, конечный цилиндр (по умолчанию, последний физический на диске), или просто размер раздела в мегабайтах, например, +300M. При задании размера в единицах, отличных от цилиндров, он всегда будет округляться до ближайшего числа, кратного целому количеству последних. Так что не следует удивляться, если вместо искомого раздела в 20 Мбайт возникнет 16-мегабайтный, а вместо 22-мегабайтного — раздел в 24 Мбайт.
Создаваемый раздел автоматически получает статус Linux native (номер 83). Чтобы изменить его (а, скажем, для swap-раздела это необходимо), дается команда t и вводится код требуемой файловой системы. Теоретически поддерживаются практически все мыслимые файловые системы: от FAT12 до UFS (для BSD-систем). Однако сами по себе файловые системы средствами fdisk не создаются, и потому для чужых разделов потребуется их форматирование в родной среде. Тем не менее, смысл в такой операции есть — резервирование места под ОС, которые будут установлены позже, и, возможно, указание точек их монтирования.
Программа cfdisk описывается реже, хотя во многих дистрибутивах она пропагандируется как более удобная. После запуска программы выводится информация о диске (имя файла устройства, размер, число головок, секторов, цилиндров), таблица существующих разделов и меню из следующих пунктов: Bootable, Delete, Help, Maximize, Print, Quit, Type, Units, Write — для диска с существующими разделами. Если же диск не разбит, меню ограничивается пунктами Help, New, Print, Quit, Units, Write. До выбора пункта Write никаких необратимых изменений не происходит. По умолчанию размеры разделов в таблице указаны в мегабайтах. Для создания раздела выбирается пункт New, выводящий подменю: Primary, Logical, Cansel. Далее просто задается желаемый размер (в мегабайтах) и запрашивается, приписать ли раздел к началу диска или его концу. После чего остается только сохранить разбиение в таблице разделов.
Программа parted предлагается в рамках проекта GNU как универсальное средство для работы с дисковыми разделами и файловыми системами. И действительно, она позволяет создавать не только новые разделы, но и файловые системы на них, а также осуществляет проверку их целостности, удаление, перемещение, копирование и изменение размера существующих разделов. Запустив программу без опций и аргументов получим предупреждение об отсутствии гарантии, информацию о первом физическом диске системы, имя устройства в полной нотации devfs, данные о геометрии (цилиндры/сектора/головки), предупреждение о том, где кончается 1024 цилиндр и выведет приглашение командной строки.
Организация диска выполняется с помощью мнемонически прозрачных команд (print — просмотр, mkpart — создание раздела, rm — его удаление, и т.д.). Полный список доступных команд с возможными опциями и аргументами, а также краткими, но внятными комментариями можно получить, введя в командной строке (parted) help. В отличие от fdisk или cfdisk, в parted не предусмотрено специальной команды для записи изменений, все действия выполняются в реальном времени, без откладывания. Соответственно, parted требует исключительно аккуратного обращения. Однако в обмен на это предоставляет, во-первых, исключительную гибкость при задании размера и позиционировании раздела. Во-вторых, он делает доступными множество дополнительных манипуляций разделами и файловыми системами (правда, в полном объеме только для ext2fs и FAT16/FAT32, поддержка прочих пока не реализована).
Как разбивать?
Теоретически обязательно требуется два раздела: корневой (/) и раздел подкачки (linux swap). Однако практически их может потребоваться больше — в зависимости от дистрибутива, задач, размера диска, используемых файловых систем. Часто целесообразно выделение небольшого (10-20 Мбайт) раздела под каталог /boot, в котором будут размещены ядро системы и необходимые для его загрузки файлы. Этим достигается надежность системы и повышение ее производительности. Первое — за счет изоляции критически важных для загрузки (и редко изменяемых) компонентов и гарантии размещения ядра системы в пределах первых 1024 цилиндров (ядро иногда не может быть загружено с более дальних областей диска). Производительность возрастает, если сразу за таким разделом (т. е. максимально близко к началу диска) разместить раздел подкачки. Рекомендованный размер последнего для современных ядер равен удвоенному размеру оперативной памяти (но не более 2 Гбайт), минимально возможный — 128 Мбайт.
Ядро Linux не всегда может быть загружено из разделов с журналируемыми файловыми системами, например, ReiserFS. И если предполагается использование последней для корневого раздела, то необходимо выделение раздела под каталог /boot.
Для настольной машины практически обязателен раздел под каталог /home, в котором будут располагаться пользовательские данные — человеческий фактор чаще является причиной краха системы, чем все аппаратные сбои и программные ошибки, вместе взятые. Корневой раздел также требует места — именно в нем окажутся базовые компоненты системы и пользовательские программы. А дискового пространства под это нужно немало — в SB-дистрибутивах возникает необходимость большого свободного пространства для временного хранения архивов исходных кодов, результатов их распаковки и промежуточных продуктов компиляции. Так, для полного развертывания некоторых из них рекомендуется раздел в 8 Гбайт. Это, конечно, крайность, но задействовать под корневой раздел 4-5 Гбайт окажется не лишним в любом случае. Или — выделить из него в самостоятельные разделы каталоги /usr (для штатных пользовательских программ дистрибутива), /usr/local (для программ, самостоятельно собираемых из исходных кодов), /usr/X11 (для программ графического режима). В некоторых случаях создаются разделы для каталогов /tmp и /var, правда, это касается в основном серверов — на настольной машине их выделение нецелесообразно.
Какие создавать разделы, первичные или логические, вопрос спорный. Установщики многих дистрибутивов по умолчанию отдают предпочтение разделам логическим. Мое же глубокое убеждение — если четырех первичных разделов хватает (под корневой каталог, каталоги /boot, /swap и /home, к примеру), то ими лучше и ограничиться. К логическим разделам следует обращаться, только если их требуется больше (например, если уже установлена Windows и хочется оставить место под FreeBSD). И в любом случае корневой раздел должен быть первичным.
Все высказанные соображения относились к ситуации с единственным физическим диском. Если их в машине больше, то возможны варианты. Первый — вынесение на второй диск некоторых разделов, например, под каталог /home или его часть, предназначенную для резервного хранения данных. Кроме того, в этом случае рекомендуется разнесение на разные диски области подкачки путем создания на каждом самостоятельного swap-раздела половинного (но не менее 128 Мбайт каждый) размера. Это способствует повышению производительности за счет распараллеливания обращений к виртуальной памяти. Другой путь — создание программного RAID-массива, логического тома, объединяющего в себе разделы, расположенные на разных дисках. Однако использование их на настольных машинах (не серверах) представляется нецелесообразным.
В заключение напомню, что на стадии создания дисковых разделов мы отнюдь не предопределяем их назначение — раздел под каталог /boot станет таковым только после его монтирования в файловую систему.
Создание и монтирование файловых систем
Создание файловых систем на дисковых разделах (или, в терминах DOS/Windows, форматирование последних) и их монтирование (т. е. обеспечение доступа к ним со стороны ОС и пользователя) — второй этап подготовки диска к инсталляции Linux. Сами по себе эти действия не сложны, однако осознанное их выполнение требует некоторой подготовки.
Устройство файловой системы
Все файлы в Unix физически состоят из двух частей, реально локализованных в различных блоках дискового накопителя, но обязательно находящихся в одном дисковом разделе, первичном или логическом. Первая часть файла — метаданные, которые содержат файловый дескриптор (некое уникальное число), сведения о его атрибутах (принадлежности, правах доступа, времени модификации и т.д.), а также информацию о том, в каких блоках дискового раздела физически размещено содержимое файла. Метаданные каждого файла записаны в специальной области диска, называемой суперблоком, где образуют описатели inodes. Каждому существующему файлу соответствует свой inode, и именно он однозначно идентифицируется файловым дескриптором. Список inodes описателей, соответствующих существующим файлам и свободным блокам дискового раздела определяет границы файловой системы.
Суть процесса создания файловой системы на дисковом разделе состоит в создании на нем суперблока, списка inode и отведении дискового пространства под блоки данных — устройством этих дисковых областей и определяются различия между файловыми системами различных типов. В результате на новом разделе образуется единственный файл — каталог корневого (для данной файловой системы) раздела, впрочем, в некоторых случаях создается еще и каталог /lost+found, предназначенный для хранения нарушенных файлов.
Возникает вопрос, почему такой, казалось бы неотъемлемый, атрибут файла, как его имя, не обнаруживается ни в его метаданных, ни, тем более, среди его данных? В Unix имя являет собой атрибут не файла, но файловой системы. И для хранения имен файлов предназначены файлы особого типа — каталоги, которые представляют собой просто списки файловых дескрипторов идентификаторов и соответствующих им имен файлов. Поэтому идущая от MacOS и активно используемая в Windows метафора каталога как папки с документами в Unix только затемняет суть — здесь это никакое не «вместилище документов», а скорее каталожный ящик в библиотеке.
Несмотря на столь простое устройство, роль каталогов в файловой системе Unix трудно переоценить. Имена файлов, через которые они включаются в файловую систему фигурируют только в составе каталога, к которому файл приписан. Удаление имени файла (или подкаталога) из списка, представляющего собой данные его родительского каталога равносильно тому, что метаданные файла становится недоступными, а приписанные к его inode блоки данных помечаются как свободные. Чтобы сделать файловую систему доступной она со всем ее содержимым (суперблоком, списком inode, блоками данных) должна быть включена в состав какого-либо из существующих каталогов, называемого точкой монтирования. Именно это и составляет суть процесса монтирования. Результат же для монтируемой файловой системы в том, что ее корневой каталог (до сих пор безымянный) получает имя каталога — точки монтирования (mount point), содержимое которого отныне составляет список имен ее файлов и подкаталогов. Обратный процесс — размонтирование, отсоединение от точки монтирования дерева смонтированной файловой системы. Кроме того, в inode ее корневого каталога устанавливается бит чистого размонтирования (clean bit).
Выбор файловой системы
О файловой системе ext2fs написано немало. Ее отличительная особенность — очень эффективный механизм кэширования дисковых операций, что обеспечивает замечательное быстродействие, едва ли не рекордное среди известных файловых систем. Оборотная сторона — относительно слабая устойчивость при аварийном завершении работы, поскольку отложенность записи изменений файлов делает весьма высокой вероятность нарушения связи между их inode и блоками данных. Конечно, времена, когда некорректный останов Linux-машины грозил разрушением файловой системы, остались в далеком прошлом. Однако останов системы без штатного размонтирования файловых систем приводит к тому, что не устанавливается бит чистого размонтирования и утилиты обслуживания диска при перезагрузке не воспринимают их как целостные и начинают проверку, которая при современных объемах дисков отнимает время. Эта проблема решена в журналируемых файловых системах, в которых фиксируются не выполненные дисковые операции, а только предстоящие манипуляции с файлами, вследствие чего оказывается возможным самовосстановление целостности файловой системы после сбоя. Текущие версии ядра Linux поддерживают в качестве родных четыре журналируемые файловые системы: ReiserFS, ext3fs, XFS и JFS.
Файловая система ReiserFS оказалась для Linux исторически первой — она поддерживается каноническим ядром (http://www.kernel.org), начиная с первых версий ветви 2.4.x и была единственной, разработанной «с нуля» специально для этой ОС Хансом Райзером. Как и в большинстве таких систем здесь осуществляется журналирование только операций над метаданными файлов. Кроме этого, ReiserFS обладает уникальной возможностью оптимизации дискового пространства, занимаемого мелкими файлами — они целиком хранятся в своих inode, без выделения блоков в области данных и вместе с экономией места это способствует и росту производительности, так как данные и метаданные хранятся в непосредственной близости и могут быть считаны одной операцией ввода/вывода. Другая особенность ReiserFS — та, что хвосты файлов меньше чем один блок могут быть подвергнуты упаковке (режим тайлинга). Это обеспечивает около 5% экономии дискового пространства.
ReiserFS не совместима с ext2fs на уровне утилит обслуживания файловой системы, однако соответствующий инструментарий, объединенный в пакет reiserfsprogs, уже давно включается в штатный комплект современных дистрибутивов. Более серьезная проблема — загрузчики Linux (Lilo и GRUB) часто не способны загрузить ядро Linux с раздела ReiserFS, оптимизированного в режиме тайлинга. А поскольку, будучи отключенным, этот режим обладает свойством самовосстановления, пользователь может столкнуться с тем, что после пересборки ядра система откажется загружаться. Именно поэтому может быть необходимым создание раздела под каталог /boot.
В отличие от ReiserFS, ext3fs — не более чем журналируемая надстройка над классической ext2fs, разработанная в компании Red Hat и поддерживаемая ядром Linux, начиная с 2.4.16. Как следствие такого происхождения, она сохраняет со своей прародительницей полную совместимость, в том числе и на уровне утилит обслуживания (начиная с версии 1.21 объединяющего их пакета e2fsprogs). Другое преимущество — чуть ли не максимальная надежность: ext3fs является единственной системой из рассматриваемых, в которой возможно журналирование операций не только с метаданными, но и с данными.
В ext3fs предусмотрено три режима работы: полное журналирование (full data journaling), журналирование с обратной записью (writeback), а также задействуемое по умолчанию последовательное (ordered). В первом случае все новые данные сначала пишутся в файл журнала и только после этого фиксируются на диске. В случае аварийного отказа можно повторно перечитать журнал, приведя данные и метаданные в непротиворечивое состояние. Этот механизм практически гарантирует от потерь данных, однако является наиболее медленным. В режиме с обратной записью в файл журнала записываются только изменения метаданных и никакой гарантии сохранности данных он не предоставляет, однако обеспечивает наибольшее (в рамках ext3fs) быстродействие. В последовательном режиме также физически журналируются только метаданные файлов, однако, связанные с ними блоки данных логически группируются в единый модуль, называемый транзакцией. И эти блоки сохраняются перед записью на диск новых метаданных, что, хотя и не гарантирует полной сохранности но весьма способствует ей.
Файловая система XFS, в отличие от молодых ReiserFS и ext3fs, развивается на протяжении почти десяти лет — впервые она появилась для версии Irix 5.3 в 1994 г. XFS — единственная из рассмотренных 64-разрядная файловая система. Особенностями XFS являются:
- механизм allocation group - деление единого дискового раздела на несколько равных областей, имеющих собственные списки inodes и свободных блоков, для распараллеливания дисковых операций;
- логическое журналирование только изменений метаданных, но с частым сбросом их на диск для минимизации возможных потерь при сбоях;
- механизм delayed allocation - ассигнование дискового пространства при записи файлов не во время журналирования, а при фактическом сбросе их на диск, что, вместе с повышением производительности, предотвращает фрагментацию дискового раздела;
- списки контроля доступа (ACL, Access Control List) и расширенные атрибуты файлов (extended attributes), рассмотрение которых далеко выходит за рамки нынешней темы.
XFS очень сбалансированная файловая система — она почти столь же надежна, как ext3fs, и не уступает ReiserFS в быстродействии на большинстве файловых операций. А при манипуляциях с очень большими файлами XFS вне конкуренции. Не отмечалось для нее и проблем с совместимостью. Однако следует учесть, что в отличие от ReiserFS и ext2fs, поддержка которых является штатными опциями ядра Linux, XFS по сию пору (текущая версия - 2.4.19) не поддерживается каноническим ядром Линуса Торвальдса. Хотя недавнее включение такой поддержки в разрабатываемую ветвь ядра (версии 2.5.X) позволяют надеяться, что скоро эта функция станет штатной. Утилиты поддержки для XFS объединены в несколько пакетов, из которых абсолютно необходимым является xfsprogs. Хотя многие дистрибутивы Linux штатно комплектуются средствами поддержки XFS (из SB-дистрибутивов в настоящий момент это Gentoo и SMGL), обо всем этом следует помнить при предварительной разметке диска.
Практические следствия
Обычно создание файловых систем — компетенция инсталлятора, который осуществляет ее с некоторыми опциями по умолчанию, изменить которые впоследствии невозможно без переформатирования. Однако все SB-дистрибутивы допускают ручное вмешательство в этот процесс.
Если нет желания заниматься сравнительным анализом разных файловых систем нормальным выбором для всех разделов остается ext2fs. Она может быть создана любой из следующих команд - /sbin/mke2fs, /sbin/mkfs, /sbin/mkfs.ext2 с указанием файла устройства в качестве аргумента, например:
$ /sbin/mke2fs /dev/hd?#
Для создания файловой системы ext3fs можно применить ту же команду mke2fs с опцией -j, при этом она получит некоторые характеристики по умолчанию, определить которые вручную позволяет следующая форма этой команды:
$ /sbin/mke2fs -J опции_журналирования /dev/hd?#
Возможные значения опций журналирования - size=размер, задающее объем журнального файла в мегабайтах, и device=внешний_журнал подключения новой файловой системы к журналу, ранее созданному на другом дисковом разделе. Можно использовать и специальную команду /sbin/mkfs.ext3 — возможности ее идентичны /sbin/mke2fs. Но самое интересное — преобразование существующей ext2fs в ext3fs простым добавлением журнала, не только без потери данных, но и без перезапуска системы (и даже без размонтирования). Делается это командой «$ tune2fs -j /dev/hd?#», которая просто добавляет файл журнала /.journal в корневом каталоге модифицируемой файловой системы (если последняя не была размонтирована), или задействует для журнала скрытый inode (если перед модификацией файловая система была размонтирована). Обратное преобразование еще проще и осуществляется командой монтирования.
Файловая система ReiserFS создается командой /sbin/mkreiserfs из пакета reiserfsprogs. Для нее доступны многочисленные опции (-s для задания размера журнала, -f для принудительного переформатирования ранее существовавшей файловой системы иного типа, и т.д.). Во избежание неожиданностей напомню: если корневой раздел форматируется как ReiserFS, не лишним будет предусмотреть небольшой раздел под каталог /boot для размещения на нем файловой системы ext2fs.
Для создания XFS также существует собственная команда mkfs.xfs (из пакета xfsprogs). Важнейшие опции: b — задание размера блока данных; d — определение параметров области данных файловой системы; l — описание параметров журнального файла. При использовании mkfs.xfs для достижения максимальной производительности рекомендуется в явном виде задать количество allocation groups иначе оно будет определяться автоматически, что приведет к непроизводительным расходам ресурсов (лучше определить его из расчета одна allocation group на 4 Гбайт дискового пространства). Далее, по тем же причинам можно установить размер файла журнала (здесь рекомендованное значение составляет 32 Мбайт). Для дискового раздела объемом в 20 Гбайт команда приобретет вид
$ mkfs.xfs -d agcount=5 -l size=32m /dev/hda1
Команда mkfs.xfs имеет опцию -f — принудительное создание файловой системы XFS поверх любой существующей. Ее достаточно, если последняя была ext2fs. Если же XFS создается поверх ReiserFS то возможны ошибки при монтировании новой файловой системы. Впрочем, то же относится и к обратной процедуре (замене XFS на ReiserFS), а также, если любая из этих «продвинутых» файловых систем заменяется на разделе системой ext2fs. Они связаны с тем, что команда монтирования может распознать вновь созданную XFS как дефектную ReiserFS, и наоборот. Во избежание этого перед таким замещением приходится прибегать к шаманскому приему — обнулению начальных областей раздела (хранящего метаданные файловой системы) командой
$ dd if=/dev/zero of=/dev/hd?#
Ждать заполнения нулями всего устройства не обязательно — достаточно дать этой команде поработать секунд 10-20, после чего прервать ее комбинацией клавиш Control+D и перейти к созданию новых файловых систем.
И последнее, о чем следует сказать об области подкачки, созданной на этапе разбиения диска. Хотя файловой системы как таковой он не несет, но нуждается в определении, что достигается командой «$ mkswap имя_устройства», к которой следует подходить со вниманием — ее применение к обычному разделу уничтожит на нем все данные.
Монтирование
Монтирование осуществляется командой mount, требующей двух аргументов - имени файла монтируемого устройства (дискового раздела) и точки монтирования. Кроме того, желательно явным образом (с помощью опции -t) задать тип монтируемой файловой системы (особенно если это не ext2fs):
$ mount -t ext3fs /dev/hd?# /mount_point
Каталог, в который монтируется файловая система, должен быть создан заблаговременно. И желательно пустой: монтирование в каталог с файлами в современных Linux фатальных последствий не повлечет (раньше это могло привести к краху системы), но все его содержимое станет недоступным вплоть до размонтирования файловой системы. Очевидно также, что первым должен монтироваться корневой каталог (/), поскольку и /boot, и /home, и /usr, и прочие представляют собой ветви на его древе. Собственно, свои имена они и обретут только после монтирования в корневую файловую систему.
Корневая файловая система отличается от всех прочих тем, что в ней задействуется загрузочный блок. Конечно, он существует и в любой другой из файловых систем, так как возникает при их создании, но не используется за ненадобностью. И здесь возникнет вопрос, как монтировать раздел, зарезервированный под корневой, к уже существующему корневому разделу. Или, хуже того, к корневому разделу системы, которая еще не инсталлирована. Ответ таков — установщик Linux работает под управлением этой же ОС, которая имеет многие атрибуты полноценной системы, в том числе и корневую файловую систему. Другое дело, что базируется она не на каком-либо дисковом устройстве, а находится в оперативной памяти и раздел, которому суждено стать корневым, монтируется в некий каталог этой виртуальной корневой файловой системы. Уже говорилось, что существуют различные опции монтирования, способствующие повышению производительности при файловых операциях. К ним относится опция -o noatime, которая отключает обновление атрибута времени последнего доступа для обычных файлов и каталогов, соответственно. Монтирование с этой опцией целесообразно для всех типов файловых систем и всех разделов. Другие опции специфичны для файловых систем определенного типа. Так, уже упоминались три режима журналирования в ext3fs, существенно различающиеся по быстродействию и надежности. Так вот, режимы эти задаются именно при монтировании файловой системы с помощью той же опции -o, принимающей значения data=journal, data=ordered и data=writeback для режимов полного журналирования, последовательного и обратной записи, соответственно. Наконец, так же опция -o будет отвечать и за отключение режима тайлинга в файловой системе ReiserFS, для чего ей нужно придать значение notail.
За отсутствием файловой системы swap-раздел в монтировании не нуждается, но должен быть активизирован, для чего служит команда swapon.
Алексей Федорчук (fedorchuk@geo.tv-sign.ru) — сотрудник Геологического института РАН (Москва)
Файловые системы в UNIX
Файловой системой называют часть ядра ОС, которая управляет организацией файлов и операциями над ними: в этом аспекте в одном ряду с файловой системой выступают система управления процессами и система ввода/вывода. Файловая система — это универсальный интерфейс доступа ко всем ресурсам, как локальной машины, так и компьютеров, объединенных в сеть. Универсальность интерфейса выражается в том, что все, что имеется в машине (и в сети) физически, представляется в виде файлов. Метафора файла охватывает не только компоненты программ и пользовательские данные, но и символьные и блочные устройства. Более того, интерфейс файловой системы обеспечивает доступ к протекающим в системе процессам. И даже средства межпроцессорного взаимодействия предстают в виде файлов особого типа.
Файловая система — это еще и принцип организации файлов как таковых: в этом контексте говорят о файловой системе Unix или FAT, HPFS или NTFS. И, наконец, файловая система — это физический способ организации данных на некоем устройстве. Он, как правило, специфичен для конкретной ОС. Linux способна работать, с «родными» с несколькими файловыми системами, начиная от традиционной ext2fs до XFS и JFS, разработанных для ОС IRIX и AIX.
Существуют еще и виртуальные файловые системы. К ним относятся уже упоминавшаяся файловая система устройств devfs и временная файловая система в оперативной памяти tmpfs, и procfs, ответственная за представление в виде файловой системы процессов, протекающих в машине.
Наконец, файловая система в Unix — это и логическая структура каталогов и файлов, которая может объединять физические и виртуальные файловые системы самых различных типов (например, дисковые разделы с файловыми системами ext2fs и FAT16, виртуальные procfs, devfs и tmpfs), причем не только на локальной машине, но и на любой удаленной. Эта структура: иерархическая, или древовидная, начинающаяся с корневого каталога, родительского по отношению ко всем прочим, от которого ответвляются отдельные файлы и дочерние каталоги, которые, в свою очередь, могут выступать как родительские по отношению к подкаталогам более глубоких уровней вложенности.
В ОС Linux структура файловой системы обычно специфична для конкретного дистрибутива или их группы, связанной единством происхождения, поэтому нередко можно столкнуться с такими выражениями, как файловая система Red Hat или Debian. Собственно, именно исторически сложившиеся различия в иерархии каталогов являются одним из критериев обособления нескольких линий дистрибутивов Linux. Однако можно надеяться, что усилиями стандартизирующих организаций, таких, как Linux Standard Base (http://www.linuxbase.org/) и Filesystem Hierarchy Standard (http://www.pathname.com/fhs), увенчаются успехом, и можно будет говорить о единой логической файловой системе Linux, подобно тому, как это имеет место в линейке BSD.
