Создание файловых систем на дисковых разделах (или, в терминах
DOS/Windows, форматирование последних) - второй этап подготовки диска
к инсталляции Linux. Само по себе это действо - не из самых сложных,
однако осознанное его выполнение требует некоторой подготовки.
Содержание
* Необходимое введение
* Устройство файловых систем Unix-семейства
* Файловые системы Linux
* Практические следствия
* Библиография вопроса
Необходимое введение
Термин "файловая система" - один из самых многозначных в компьютерной
терминологии вообще, и в литературе, связанной с ОС Unix и ее клонами
(а Linux именно к таковым и относится) - в особенности: больше
значений имеет, пожалуй, только просто слово "система". Так сложилось
исторически, и потому значение термина приходится определять по
контексту. Мне таких значений известно как минимум пять, и нет
уверенности, что это - все возможные значения.
Во-первых, файловой системой или, иногда, подсистемой, называют часть
ядра, которая управляет организацией файлов и операциями над ними: в
этом аспекте в одном ряду с файловой системой выступают система
управления процессами и система ввода/вывода. Впрочем, именно это
значение мы пока рассматривать не будем.
Во-вторых, и это специфично для Unix и Unix-подобных ОС, файловая
система - универсальный интерфейс доступа ко всем ресурсам, как
локальной машины, так и компьютеров, объединенных в сеть любого рода -
от модемного подключения до спутникового канала. Собственно говоря,
именно задействование такого интерфейса в некоей ОС и являет собой
один из поводов для отнесения ее к семейству Unix-подобных.
Во-третьих, файловая система - это способ описания некоего физического
устройства (обычно - дискового раздела). Именно это значение
используется в термине "идентификатор типа файловой системы", о
котором говорилось в статье о дисковых разделах. Он обычно
специфичен для конкретной ОС, и потому здесь уместны термины:
DOS-раздел, расширенный (Extended) раздел DOS, раздел Linux native и
так далее. Хотя большинство всамделишних операционных систем способны
тем или иным образом опознавать "неродные" для них идентификаторы и
обращаться к данным на них. А в Linux в качестве "родных" (native)
рассматривает дисковые разделы, идентифицированные целым рядом
файловых систем в третьем понимании термина - от истинно родного Linux
native до Extended DOS, включая логические тома (LVM) о которых
говорилось в соответствующей статье, и программные RAID-массивы.
Здесь следует отметить, что помимо файловых систем физических (то есть
надстраивающих реальные дисковые устройства, почему в этом контексте
нередко фигурирует выражение - disk based file system), существуют и
виртуальные файловые системы различных типов. К ним относятся и
файловая система устройств - devfs, и временная файловая система в
оперативной памяти - tmpfs, и procfs - система, ответственная за
представление в виде файловой системы (уж простите за тавтологию)
процессов. Иногда используются и файловые системы промежуточного типа,
например, виртуальные диски (RAM-диски). Подобно tpmfs, они существуют
только в оперативной памяти, однако в остальном ведут себя также, как
и файловые системы disk-based.
В четвертых, под файловыми системами понимается внутренняя управляющая
структура, позволяющая хранить, идентифицировать и отыскивать данные,
ну и, конечно, манипулировать ими. Такие структуры, с одной стороны,
специфичны для операционных систем, как FAT16 (со всеми ее вариациями
типа VFAT или FAT32) для DOS, UFS для FreeBSD или Ext2fs - для Linux.
С другой же - структуры управления файлами в ряде операционок строятся
по близким принципам, чему ярким примером служат файловые системы
Unix- и Unix-подобных ОС . И потому они могут быть объединены в одно
семейство, противопоставляемое FAT-семейству, например.
Кроме того, Linux в настоящее время способен работать с управляющими
структурами различных типов - от Ext3fs, являющей собой надстройку над
традиционной Ext2fs, до XFS и JFS, разработанных первоначально для
версий Unix от SGI и IBM, соответственно, а также ReiserFS. Нет
запрета и на размещение Linux'а на файловой системе типа FAT (хотя и
резонов к тому - нет также).
Добавлю, что в списке из предыдущего абзаца перечислены только
файловые системы, способные нести базовые компоненты Linux, отвечающие
за ее запуск и минимальную функциональность. Что же касается обмена
данными - таковой возможен из Linux'а практически со всеми известными
файловыми системами, хотя с некоторыми из них (например, NTFS или
HPFS) - только в режиме чтения.
Наконец, в пятых, файловая система в Unix - это и логическая структура
каталогов и файлов, которая объединяет и физические, и виртуальные
файловые системы самых различных типов (например, дисковые разделы с
файловыми системами Ext2fs и FAT16, виртуальные procfs, devfs и
tmpfs), причем не только на локальной машине, но и и на любой
удаленной. Структура эта - иерархическая, или древовидная,
начинающаяся с корневого каталога, родительского по отношению ко всем
прочим, от которого ответвляются отдельные файлы и дочерние каталоги,
которые, в свою очередь, могут выступать как родительские по отношению
к подкаталогам более глубоких уровней вложенности.
Положение дел в настоящий момент таково, что в Linux структура
файловой системы обычно специфична для конкретного дистрибутива или их
группы, связанной единством происхождения. Поэтому нередко можно
столкнуться с такими выражениями, как файловая система Red Hat или
Debian. Собственно, именно исторически сложившиеся различия в иерархии
каталогов являются одним из критериев обособления нескольких линий
дистрибутивов Linux. Как, впрочем, и потенциальной причиной их
несовместимости. Однако можно надеяться, что усилиями
стандартизирующих организаций, таких, как Linux Standard Base и
Filesystem Hierarchy Standard, русский перевод стандарта - на
сайте Виктора Костромина http://linux-ve.net), увенчаются успехом, и можно будет
говорить о единой логической файловой системы Linux, подобно тому, как
это имеет место в ОС линии BSD.
В контексте настоящей статьи нас интересует только четвертый аспект
файловых систем, то есть создание управляющих файлами структур,
базируемых на дисках (вернее, их разделах).
Устройство файловых систем Unix-семейства
В этом разделе будет говориться о предметах, общих для всех Unix. Все
файлы в Unix физически состоят из двух частей, реально локализованных
в различных блоках дискового накопителя, но обязательно находящихся в
одном дисковом разделе, первичном или логическом.
Первая часть файла - его т.н. метаданные, которые содержат файловый
дескриптор (это просто некое уникальное число), сведения о его
атрибутах (принадлежности, правах доступа, времени модификации и
т.д.), а также информацию о том, в каких блоках дискового раздела
(которые так и называются - блоки данных) физически размещено
содержимое файла - те самые последовательности байтов, которые
образуют доступный пользователю ASCII-текст или исполняемый модуль
программы.
Метаданные каждого файла записаны в специальной области диска,
называемой суперблоком, где образуют т.н. inodes (от information nodes
- информационные узлы). Каждому существующему файлу соответствует свой
inode, и именно он однозначно идентифицируется файловым дескриптором.
А сам по себе список inodes, соответствующих как существующим файлам,
так и свободным блокам дискового раздела, и определяет границы
файловой системы, то есть сколько файлов может быть в ней создано.
Так вот, суть процесса создания файловой системы на дисковом разделе
(или, в понимании DOS/Windows, его форматирования) - в создании на нем
суперблока (или, в некоторых файловых системах, нескольких его копий),
списка inodes и отведении дискового пространства под блоки данных (а
также загрузочного блока, о котором будет сказано ниже), а устройством
этих дисковых областей определяются различия между файловыми системами
различных типов. В результате на новом разделе образуется единственный
файл - каталог корневого (для данной файловой системы) раздела (в
некоторых случаях создается еще и каталог /lost+found, предназначенный
для хранения нарушенных файлов).
Возникает вопрос, почему такой, казалось бы неотъемлемый, атрибут
файла, как его имя, не обнаруживается ни в его метаданных, ни, тем
более, среди его данных. Ответ прост: в Unix имя являет собой атрибут
не файла, но файловой системы (в пятом, логическом, понимании
термина). И для хранения имен файлов предназначены файлы особого типа
- каталоги (в Unix есть и другие типы файлов, например, упомянутые
выше файлы устройств). Они представляют собой просто списки файловых
дескрипторов идентификаторов и соответствующих им имен файлов. Поэтому
идущая от MacOS и активно используемая в Windows метафора каталога как
папки с документами - в Unix только затемняет суть дела: здесь это
скорее именно каталожный ящик в библиотеке.
Не смотря на столь простое устройство, роль каталогов в файловой
системе Unix трудно переоценить: имена файлов, через которые они
включаются в файловую систему (и через которые пользователь получает
доступ к их содержимому), фигурируют только в составе каталога, к
которому файл приписан - и больше нигде в системе. Так что удаление
имени файла (или подкаталога) из списка, представляющего собой данные
его родительского каталога (который, конечно, также имеет свой inode и
файловый дескриптор, приписанный к каталогу, расположенному уровнем
выше в иерархии файловой системы, и так далее) равносильно тому, что
метаданные файла становится недоступными, а приписанные к его inode
блоки данных помечаются как свободные. Именно так осуществляется
удаление файла командой rm или файловым менеджером типа Midnoght
Commander.
Нас, однако, сейчас интересует прямо противоположное - сделать
файловую систему доступной. Из сказанного понятно, что для этого она
со всем ее содержимым (суперблоком, списком inode, блоками данных)
должна быть включена в состав какого-либо из существующих каталогов,
называемого точкой монтирования. Именно это и составляет суть процесса
монтирования. Результат же для монтируемой файловой системы - в том,
что ее корневой каталог (до сих пор безымянный) получает имя каталога
- точки монтирования (mount point), содержимое которого отныне
составляет список имен ее файлов и подкаталогов. Обратный процесс -
размонтирование, следствием чего является отсоединение от точки
монтирования дерева смонтированной файловой системы. Кроме того, в
inode ее корневого каталога устанавливается т.н. бит чистого
размонтирования (clean bit). Впрочем, вопросам монтирования и
размонтирования файловых систем будет посвящена специальная статья.
Пока же рассмотрим особенности файловых систем, используемых в
Linux'е.
Файловые системы Linux
Ext2fs
До недавнего времени список истинно родных (native) файловых систем
для Linux ограничивался единственной - ext2fs (правда, Linux способен
загрузиться и работать с FAT-раздела, но об этом мне даже не хочется
говорить). Название это расшифровывается как "вторая расширенная
файловая система"; "расширенная" она - по сравнению с файловой
системой ОС minix, послужившей прототипом Linux, "вторая" - потому что
ранние версии Linux базировались на Extfs с более ограниченными
возможностями.
О файловой системе Ext2fs написано немало (см. дополнительные
источники). Поэтому замечу только, что по способу организации хранения
данных она - типичная представительница файловых систем Unix.
Отличительная ее особенность - наличие нескольких копий суперблока,
что повышает надежность хранения данных. Кроме того, для характерен
очень эффективный механизм кэширования дисковых операций, что
обеспечивает замечательное их быстродействие - едва ли не рекордное
среди известных мне файловых систем. Оборотная сторона чего, однако, -
относительно слабая устойчивость при аварийном завершении работы
(вследствие мертвого зависания или отказа питания), поскольку
отложенность записи изменений файлов делает весьма высокой вероятность
нарушения связи между их inodes и блоками данных.
Конечно, времена, когда некорректный останов Linux-машины грозил
полным разрушением файловой системы, остались в далеком прошлом.
Однако в любом случае останов системы без штатного размонтирования
файловых систем приводит к тому, что в них не устанавливается
упомянутый выше "бит чистого размонтирования". А без этого утилиты
обслуживания диска (такие, как программа проверки fsck) при
перезагрузке не воспринимают их как целостные и начинают проверку,
которая при современных объемах дисков может занять немалое время.
О журналируемых файловых системах
Проблема нарушения целостности файловой системы при некорректном
завершении работы в большей или меньшей мере характерна для всех ОС
семейства Unix. И потому с давних пор в них разрабатываются т.н.
журналируемые файловые системы. Журнал -- это нечто вроде log-файла
дисковых операций, в котором фиксируются не выполненные, а только
предстоящие манипуляции с файлами, вследствие чего оказывается
возможным самовосстановление целостности файловой системы после сбоя.
Во избежание недоразумений следует подчеркнуть, что журналирование
направленно на обеспечение целостности файловой системы, но ни в коем
случае не гарантирует сохранность пользовательских данных как таковых.
Так, не следует ожидать, что журналирование волшебным образом
восстановит не сохраненные перед сбоем изменения документа,
загруженного в текстовый редактор.
Более того, в большинстве журналируемых файловых систем фиксируются
грядущие операции только над метаданными изменяемых файлов. Обычно
этого достаточно для сохранения целостности файловой системы и, уж во
всяком случае, предотвращения долговременных их проверок, однако не
предотвращает потери данных в аварийных ситуациях. В некоторых из
файловых систем возможно распространение журналирования и на область
данных файла. Однако, как всегда, повышение надежности за счет этого
оплачивается снижением быстродействия.
Текущие версии ядра Linux поддерживают в качестве нативных четыре
журналируемые файловые системы: ReiserFS и Ext3fs, специфичные для
этой ОС, XFS и JFS - результаты портирования в Linux файловых систем,
разработанных первоначально для рабочих станций под ОС Irix (SGI) и
AIX (IBM), соответственно. Правда, широкое признание получили только
три первых, так что о JFS я пока говорить не буду.
ReiserFS
Файловая система ReiserFS оказалась для Linux исторически первой из
журналируемых - она поддерживается каноническим ядром c
http://www.kernel.org, начиная с первых версий ветви 2.4.x (в
настоящее время существуют патчи, позволяющие использовать ее и с
версиями ветви 2.2.xx). И была единственной, разработанной "с нуля"
специально для этой ОС Хансом Райзером и его фирмой Namesys. Как и
в большинстве рассмотренных, в ReiserFS осуществляется журналирование
только операций над метаданными файлов. Что, при определенном снижении
надежности, обеспечивает высокую производительность: по моим
наблюдениям, на большинстве типичных пользовательских задач она лишь
незначительно уступает Ext2fs. А на такой, достаточно обычной,
операции, как копировании большого количества мелких файлов,
существенно ее опережает.
Кроме этого, ReiserFS обладает уникальной (и по умолчанию
задействованной) возможностью оптимизации дискового пространства,
занимаемого мелкими, менее одного блока, файлами (а следует помнить,
что в любой Unix-системе такие файлы присутствуют в изобилии): они
целиком хранятся в своих inode, без выделения блоков в области данных
- вместе с экономией места это способствует и росту
производительности, так как и данные, и метаданные (в терминах
ReiserFS - stat-data) файла хранятся в непосредственной близости и
могут быть считаны одной операцией ввода/вывода.
Вторая особенность ReiserFS - то, что т.н. хвосты файлов, то есть их
конечные части, меньшие по размеру, чем один блок, могут быть
подвергнуты упаковке. Этот режим (tailing) также включается по
умолчанию при создании ReiserFS, обеспечивая около 5% экономии
дискового пространства. Что, правда, несколько снижает быстродействие,
и потому режим тайлинга можно отменить при монтировании файловой
системы. Однако упаковка хвостов автоматически восстанавливается после
перекомпиляции ядра - что, как будет сказано чуть ниже, требует
внимательного отношения.
ReiserFS не совместима с Ext2fs на уровне утилит обслуживания файловой
системы. Однако соответствующий инструментарий, объединенный в пакет
reiserfsprogs, уже давно включается в штатный комплект современных
дистрибутивов (или, в крайнем случае, может быть получен с сайта
Namesys).
Более серьезная проблема с совместимостью - в том, что
распространенные загрузчики Linux (и Lilo, и GRUB - хотя и по разным
причинам) часто не способны загрузить ядро Linux с раздела ReiserFS,
оптимизированного в режиме тайлинга. А поскольку, будучи отключен,
этот режим обладает свойством самовосстановления, пользователь может
столкнуться с тем, что после пересборки ядра система просто откажется
загружаться. Именно поэтому выше я упоминал, что создание раздела под
каталог /boot может быть необходимым.
Ext3fs
В отличие от ReiserFS, Ext3fs - не более чем журналируемая надстройка
над классической Ext2fs, разработанная Стивеном Твиди в компании Red
Hat и поддерживаемая ядром Linux, начиная с версии 2.4.16. Как
следствие такого происхождения, она сохраняет со своей
прародительницей полную совместимость, в том числе и на уровне утилит
обслуживания (начиная с версии 1.21 объединяющего их пакета
e2fsprogs). И переход от ext2fs к ext3fs может быть осуществлен
простым добавлением файла журнала к первой, не только без
переформатирования раздела, но даже и без рестарта машины.
Из этого вытекает первое преимущество ext3fs, особенно весомое в
случае большого парка компьютеров. Второе же - чуть ли не максимальная
надежность: ext3fs является единственной системой из рассматриваемых,
в которой возможно журналирование операций не только с метаданными, но
и с данными файлов.
В Ext3fs предусмотрено три режима работы - полное журналирование (full
data journaling), журналирование с обратной записью (writeback), а
также задействуемое по умолчанию последовательное (ordered).
Режим полного журналирования, как легко догадаться из названия,
распространяется и на метаданные, и на данные файлов. Все их изменения
сначала пишутся в файл журнала и только после этого фиксируются на
диске. В случае аварийного отказа журнал можно повторно перечитать,
приведя данные и метаданные в непротиворечивое состояние. Этот
механизм практически гарантирует от потерь данных, однако является
наиболее медленным.
В режиме отложенной записи, напротив, в файл журнала записываются
только изменения метаданных файлов, подобно всем рассмотренным ниже
файловым системам. То есть никакой гарантии сохранности данных он не
предоставляет, однако обеспечивает наибольшее (в рамках Ext3fs)
быстродействие.
В последовательном режиме также физически журналируются только
метаданные файлов, однако связанные с ними блоки данных логически
группируются в единый модуль, называемый транзакцией (transaction). И
эти блоки записываются перед записью на диск новых метаданных на диск,
что, хотя и не гарантирует сохранности данных, весьма последней
способствует. Причем - при меньших накладных расходах по сравнению с
полным журналированием, обеспечивая промежуточный уровень
быстродействия.
Однако, по моим наблюдениям Ext3fs ни в одном из режимов не может
похвастаться высокой производительностью при решении настольных
пользовательских задач. А в режиме полного журналирования возможны
ситуации, вызывающие на некоторое время полный паралич машины.
XFS
Файловая система XFS, в отличие от молодых ReiserFS и ext3fs,
развивается для фирмой SGI на протяжении почти десяти лет - впервые
она появилась в версии Irix 5.3, вышедшей в 1994 г. Но в Linux она
была портирована лишь недавно (текущая ее версия - 1.1, свободно
доступна с сайта SGI's XFS page - http://oss.sgi.com/projects/xfs) и
по сию пору не поддерживается официальным ядром.
XFS - единственная 64-разрядная файловая система из рассмотренных.
Однако уникальность ее - не только в этом. Особенностями XFS являются:
* механизм allocation group, то есть деление единого дискового
раздела на несколько равных областей, имеющих собственные списки
inodes и свободных блоков, для распараллеливания дисковых
операций;
* логическое журналирование только изменений метаданных, но - с
частым сбросом их на диск для минимизации возможных потерь при
сбоях;
* механизм delayed allocation - ассигнование дискового пространства
при записи файлов не во время журналирования, а при фактическом
сбросе их на диск, что, вместе с повышением производительности,
предотвращает фрагментацию дискового раздела;
* списки контроля доступа (ACL, Access Control List) и расширенные
атрибуты файлов (extended attributes), рассмотрение которых далеко
выходит за рамки нынешней темы.
В результате XFS предстает как очень сбаллансированная файловая
система: она почти столь же надежна, как Ext3fs, и не очень уступает
ReiserFS в быстродействии на большинстве файловых операций. А при
манипуляциях с (очень) большими файлами XFS - просто вне конкуренции:
как легко догадаться по имени фирмы-разработчика, она ориентирована на
работу с мультимедийными приложениями с их огромными потоками данных.
Не отмечалось для нее и проблем с совместимостью.
Все сказанное позволяет сделать вывод, что XFS - оптимальная файловая
система для Linux. Однако следует учесть: в отличие от ReiserFS и
ext2fs, поддержка которых является штатными опциями ядра Linux, XFS по
сию пору (текущая версия - 2.4.19) не поддерживается каноническим
ядром Линуса Торвальдса (тем, которое можно получить с
http://www.kernel.org). Хотя недавнее включение такой поддержки в
разрабатываемую ветвь ядра (версии 2.5.X) позволяют надеяться, что
скоро эта функция станет штатной.
Возможность работы с XFS обеспечивает специальный патч
(xfs-2.4.1X-all-i386.bz2), который можно получить с сайта SGI (http://oss.sgi.com/projects/xfs)
вместе с соответствующими утилитами поддержки: традиционные средства
e2fsprogs, для XFS не пригодны. Утилиты поддержки для XFS объединены в
несколько пакетов, из которых абсолютно необходимым является xfsprogs.
Обо всем этом следует помнить при предварительной разметке диска.
Критерии выбора
Таким образом, каждая из четырех рассмотренных файловых систем имеет
свою уникальную положительную особенность (даже Ext2fs - как бы то ни
было, лидером по суммарному быстродействию остается она), и как
минимум один недостаток (который, тем не менее, не служит препятствием
к ее использованию). Так что выбор файловой системы должен
определяться задачами пользователя и характером преобладающих его
данных.
Кроме этого, если, как рассказывалось в статье про LVM (http://linuxshop.ru/unix4all/?cid=13&id=62),
максимально разгрузить корневую файловую систему, выделив в логические
тома отдельные ее ветви, возможно и комбинированное использование
файловых систем. То есть подбор для каждого из дисковых разделов
наиболее подходящей к его содержанию управляющей структуры.
Так, ранее неоднократно говорилось, что Ext2fs - наиболее подходящий
выбор для загрузочного раздела (а при использовании в качестве
загрузчика GRUB - это почти обязательное требование). Кроме того,
Ext2fs вполне подходит для таких ветвей, как /tmp или /var. Для
первого, по определению, устойчивость к сбоям не критична. Для второго
же определяющим требованием является быстродействие (так, в Source
Based дистрибутивах типа Gentoo /var задействуется для хранения
временных продуктов компиляции, и быстродействие файловых операций в
нем несколько способствует ускорению сборки пакетов). Наконец, на
настольной машине Ext2fs можно применить и для корневой файловой
системы - ведь при дробном разбиении диска в корне остается минимум
редко изменяемых компонентов.
С другой стороны, корень - наиболее критичный в отношении устойчивости
элемент файловой системы. И потому оптимальным для него представляется
файловая система Ext3fs, как наиболее устоявшаяся. Кроме того, в
экстремальных ситуациях она может быть без проблем смонтирована как
Ext2fs. Для разделов типа /usr и /usr/local Ext3fs также видится
вполне подходящим вариантом.
Наиболее важная часть файловой системы настольной машины с точки
зрения пользователя - его, пользовательские, данные, то есть каталог
/home (ибо систему можно переустановить, а вот потеря данных может
быть невосполнимой). Однако это - и наиболее изменяемая ее часть, что
предъявляет высокие требования к быстродействию файловых операций. И
поэтому Ext3fs - не лучшее (ИМХО) решение для каталога /home, более
целесообразно разместить здесь какую-либо из "быстрых" журналируемых
файловых систем, ReiserFS или XFS. Выбор между ними определяется
личными предпочтениями и характером данных (пользуясь случаем, замечу,
что быстродействие JFS, по моим наблюдениям над типичными
пользовательскими манипуляциями, оставляет желать лучшего).
Очевидно, что быстродействие XFS при работе с файлами (очень) большого
размера делает ее предпочтительной, если речь идет об обработке
изображений, мультимедийном контенте, картографической информации и
т.д. В то же время преимущества ReiserFS сказываются в основном при
работе с файлами (очень) маленького размера (менее блока файловой
системы), каковых среди пользовательских данных обычно бывает мало. И
потому мое личное мнение однозначно - и высказывается в пользу XFS. К
тому же собственный опыт общения с ReiserFS был неблагоприятен,
особенно в сочетании с технологией LVM. XFS же, напротив, по моим
впечатления идеально с ней гармонирует.
Подведем итог - оптимальной мне видится следующее сочетание файловых
систем:
* Ext3fs - для корневого каталога (/) и каталога /usr (а также
/usr/local и /usr/X11R6, если таковые обособляются в отдельные
ветви);
* Ext2fs - для загрузочного /boot, каталогов /tmp и /var;
* XFS - для раздела под домашние каталоги (/home).
Повторяю, это лишь мое мнение, основанное на опыте настольного
применения Linux - для серверов различного рода оно силы не имеет.
Практические следствия
Надеюсь, предыдущий раздел дал достаточно информации для выбора
файловой системы, наиболее подходящей к конкретным условиям. И потому
далее вкратце рассмотрим последовательность действий после того, как
выбор осуществлен.
Обычно при установке Linux создание файловых систем - компетенция
инсталлятора, который осуществляет его с некоторыми опциями по
умолчанию. В контексте рассмотренного в предыдущем разделе ясно, что
опции эти не всегда будут лучшими с точки зрения пользователя.
Изменить же характеристики, определенные для файловой системы при ее
создании, невозможно без повторного выполнения этого процесса (и,
соответственно, потери данных). Однако все SB-дистрибутивы допускают
ручное вмешательство в процедуру создания файловой системы, а в
Gentoo, например, это - просто единственный способ ее выполнения.
Файловая система Ext2fs может быть создана любой из следующих команд -
/sbin/mke2fs, /sbin/mkfs, /sbin/mkfs.ext2 с указанием файла устройства
в качестве аргумента, например:
$ /sbin/mke2fs /dev/hd?#
Каждая из этих команд (а /sbin/mkfs.ext2 - обычно символическая ссылка
на /sbin/mke2fs) имеет ряд опций, как то: -b для определения размера
блока файловой системы (возможные значения - 1024, 2048 или 4096 байт,
по умолчанию принято последнее),-c для проверки испорченных участков
диска, -N и -i для задания числа inodes и количества байт на один
узел, соответственно; с деталями можно ознакомиться на соответствующей
man-странице, например, man (8) mke2fs.
Для создания файловой системы 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 для
принудительного переформатирования ранее существовавшей файловой
системы иного типа, и т.д.), с которыми можно ознакомиться посредством
man (8) mkreiserfs. И во избежание неожиданностей напомню: если
корневой раздел форматируется как ReiserFS, не лишним будет
предусмотреть небольшой раздел под каталог /boot для размещения на нем
файловой системы ext2fs.
Для создания XFS также существует собственная команда mkfs.xfs (из
пакета xfsprogs). В ней предусмотрено несколько опций, каждая из
которых имеет ряд субопций, принимающих численные значения. Важнейшие
из них:
* -b, которая посредством субопции size=## позволяет задать размер
блока данных в байтах, который должен быть кратен размеру страницы
оперативной памяти (для платформы i386 - 4 Кбайт) и может
варьировать в диапазоне от 512 до 65536 (по умолчанию - 4096);
* -d, определяющая параметры области данных файловой системы, такие,
как количество самостоятельных областей раздела (Allocation
groups, субопция agcount), или, напротив, их размер (субопция
agsize);
* -l, специфицирующая параметры журнального файла, например, его
размер (субопция size).
При использовании mkfs.xfs для достижения максимальной
производительности рекомендуется в явном виде задать количество
allocation groups - иначе оно будет определяться автоматически, что
ведет к непроизводительным расходам ресурсов. Это делается из расчета
- одна allocation group на 4 Гбайт дискового пространства. Далее можно
установить размер файла журнала - здесь рекомендованное значение
составляет 32 Мбайт. То есть для дискового раздела объемом в 20 Гбайт
команда приобретет вид
$ mkfs.xfs -d agcount=5 -l size=32m /dev/hda1
Кроме всех перечисленных, команда mkfs.xfs имеет опцию -f (от force) -
принудительное создание файловой системы XFS поверх любой
существующей. Ее достаточно, если последняя была ext2fs (и, исходя из
общих соображений, ext3fs, хотя я этого не проверял). Если же XFS
создается поверх ReiserFS - после этого возможны ошибки при
монтировании новой файловой системы. Впрочем, то же относится и к
обратной процедуре (замене XFS на ReiserFS), а также, если любая из
этих "продвинутых" файловых систем заменяется на разделе системой
ext2fs. Они связаны с тем, что команда монтирования может распознать
новосозданную XFS как дефектную ReiserFS, и наоборот.
Во избежание этого перед таким замещением приходится прибегать к
несколько шаманскому приему - обнулению начальных областей раздела
(хранящего метаданные файловой системы) командой
$ dd if=/dev/zero of=/dev/hd?#
Ждать заполнения нулями всего устройства не обязательно - достаточно
дать этой команде поработать секунд 10-20, после чего прервать ее
комбинацией клавиш Control+D и перейти к созданию новых файловых
систем.
И последнее, о чем следует сказать - о swap-разделе, созданном на
этапе разбиения диска. Хотя файловой системы как таковой он не несет,
но нуждается в определении, что достигается командой
$ mkswap имя_устройства
к которой следует подходить со вниманием - применение ее к обычному
разделу уничтожит на нем все данные.