Необходимая преамбула
Понятие файловой системы — одно из самых многозначных в околокомпьютерной терминологии; больше значений имеет, пожалуй, только просто слово «система». Во-первых, файловая система — это система устройства файлов как таковых: в этом аспекте говорят о файловой системе UNIX или вариациях на тему FAT, например.
Во-вторых, файловая система — это физический способ организации данных на дисковом разделе. Он часто специфичен для конкретной ОС, и потому здесь уместны такие термины, как файловая система Linux или там BSD. Хотя, некоторые ОС (и Linux тут — один из самых ярких примеров) могут работать с различными файловыми системами, как с родными.
Заметим вскользь, что, помимо физических (так называемых disk-based) файловых систем, существуют виртуальные файловые системы. Их множество: от памятных по DOS RAM-дисков до файловой системы устройств (devfs) и даже файловых систем, отображающих процессы в системе (procfs).
В третьих, файловая система — это логическая структура каталогов и файлов, объединяющая в себе базируемые на дисках (вернее, их разделах) и виртуальные файловые системы.
В современном Linux структура файловой системы обычно специфична для конкретного дистрибутива, поэтому можно столкнуться с выражениями, типа файловая система Red Hat или Debian (будем надеяться, что усилия стандартизирующих организаций переведут эти выражения в разряд нецензурных).
Наконец, во всех «юниксах» (и это отличает их от любых других ОС) файловая система — универсальный интерфейс доступа ко всему, что только имеется в системе: от текстовых и исполнимых файлов до физических устройств (дисков, принтеров, модемов) и даже (через помянутую procfs) к протекающим в ней процессам.
Осветить все аспекты файловых систем за один раз мне возможным не представляется. И потому нынче разговор будет только о том, что имеет отношение к процессу установки Linux — о disk-based файловых системах (второе значение слова).
Хотя для начала придется затронуть аспект организации хранения данных в Linux (файловая система в первом понимании), а под занавес — чуть коснуться и логической структуры файловой системы (в третьем значении термина). При этом — все время держа в голове четвертый аспект этого понятия.
Файловая прелюдия
В этом разделе будет говориться о предметах, общих для всех «юниксов». А все, что ни на есть в работающей UNIX-системе (вспомним последнюю фразу преамбулы), суть файлы. Столь многогранное употребление этого слова требует некоторого упорядочивания. И файлы в UNIX разделяются на несколько типов, примером чему — упомянутые ранее файлы устройств.
Рассмотрение их далеко выходит за намеченные на сегодня рамки, однако о двух типах упомянуть необходимо. Это обычные (так называемые регулярные) файлы, к которым относятся все файлы в понимании DOS / Windows (текстовые, исполняемые, файлы данных в собственных форматах), и каталоги, важность которых в UNIX станет ясной из дальнейшего.
Обычные файлы (впрочем, это относится и ко всем прочим их типам) в UNIX состоят как бы из двух частей, разобщенных в пространстве на диске (но обязательно находящихся в одном дисковом разделе, сиречь файловой системе во втором понимании термина).
Первая часть — область метаданных, в которой записываются идентификатор диска (это просто некое уникальное число), сведения об атрибутах файла (принадлежности, правах доступа, времени модификации и т. д. — это очень важные понятия, но говорить о них здесь неуместно), а также информация о том, в каких блоках дискового раздела физически размещена область данных файла.
Последняя же содержит те самые последовательности байтов, которые образуют доступный пользователю текст в формате ASCII или откомпилированный бинарник.
Заостряю внимание — имя файла не обнаруживается ни в его метаданных, ни среди данных. Откуда же оно берется? Имя — атрибут не файла, а файловой системы (в третьем понимании термина). И именно для его хранения предназначены файлы особого типа — каталоги (сиречь директории, по-досовски).
Поэтому, хотя каталог являет собой просто список файловых идентификаторов и соответствующих им имен (почему поведшийся от Windows (или — от Mac OS?) эвфемизм для каталога как папки с документами в UNIX только затемняет суть дела: здесь это скорее «каталожный» ящик в библиотеке; или, если угодно, простая база данных), роль его трудно переоценить.
Имена файлов, через которые они включаются в файловую систему (и через которые пользователь получает доступ к их содержимому), фигурируют только в составе каталога, к которому файл приписан — и больше нигде (!) в системе. И потому удаление файла в UNIX — это манипулирование не с ним самим, а с данными его каталога. Который, конечно, также имеет свои метаданные и идентификатор, приписанный к каталогу, расположенному уровнем выше в иерархии файловой системы.
Такой способ организации связи между контентом файла (данными и метаданными) и его именем называется жесткой ссылкой (hard link). Из него следует, что один и тот же набор данных и метаданных может иметь любое количество имен.
Именно это подразумевается, когда речь идет о файлах дисковых устройств: файлы /dev/ide/host0/bus0/target0/lun0/part1 и /dev/discs/disc0/part1 по сути своей не более, чем один и тот же набор данных, приписанных к разным каталогам. Впрочем, об этом здесь упоминаю лишь в порядке информации к размышлению.
И эти сведения (каюсь — очень неполные) потребуются нам при размещении файловых систем на ранее созданных разделах и их монтировании в файловую систему Linux — надеюсь, уже не нужно добавлять, где этот термин выступает во втором значении, а где — в третьем?
Файловая фуга
Надеюсь, опять-таки, что наша конкретно-шкурная задача — понять процесс установки Linux — не была забыта в ходе затянувшейся прелюдии. Обращаемся к фуге, то есть посмотрим, какие же файловые системы мы можем создать на давешних разделах.
До недавнего времени истинно родной для Linux была одна-единственная файловая система — ext2fs. По способу организации хранения данных это — типичная представительница UNIX-клана. За счет эффективного кэширования дисковых операций она обеспечивает замечательное их быстродействие — суммарно чуть ли не рекордное, среди известных мне.
Оборотная сторона чего — относительно слабая устойчивость к сбоям, типа аварийной остановки или отключения питания. Ведь если в этот момент происходит запись файлов, то вероятность нарушения связи между областями метаданных и данных (сиречь нарушение целостности файловой системы) достаточно велика.
Времена, когда некорректный останов Linux-машины грозил полным разрушением файловой системы, слава Богу, остались в далеком прошлом. Однако в любом случае он чреват ожиданием проверки дисковых накопителей соответствующей утилитой, что при нынешних их объемах может затянуться на неприлично долгое время. И потому в UNIX с давних пор развиваются журналируемые файловые системы.
Обсуждать механизм журналирования еще не время. В контексте темы замечу только, что журнал — это нечто вроде лог-файла дисковых операций, в котором фиксируются не выполненные, а только предстоящие манипуляции с метаданными, вследствие чего оказывается возможным самовосстановление целостности файловой системы после сбоя (подчеркиваю — именно целостности файловой системы, но не данных как таковых: не следует ожидать, что журналирование волшебным образом восстановит не сохраненные перед сбоем изменения файла).
Разумеется, повышение надежности за счет журналирования оплачивается снижением быстродействия.
Ныне журналируемые файловые системы добрались и до Linux — причем практически все поддерживаются как родные. Однако наибольшее признание получили три — ReiserFS, ext3fs, XFS. Первая из перечисленных — была и исторически первой в Linux, однако обзор их целесообразно начать со второй позиции списка. Ибо ext3fs — не более чем журналируемая надстройка над классической ext3fs, сохраняющая с ней полную совместимость, в том числе и на уровне утилит обслуживания (типа создания файловых систем, проверки их целостности и т. д.).
Из чего вытекает первое ее преимущество. Второе же — чуть ли не максимальная надежность: ext3fs является единственной системой из рассмотренных, в которой возможно журналирование операций не только с метаданными, но и с данными файлов, полное или частичное (по умолчанию).
Как всегда в этой жизни, расплата не замедлит последовать: в виде низкой производительности дисковых операций. В режиме полного журналирования возможны ситуации, вызывающие на некоторое время полный паралич машины (примерно как в Windows при одновременной проверке диска и форматировании дискеты).
Конечно, режим экстремальной надежности может быть отключен, но и в более либеральных модах быстродействие ext3fs оставляет желать лучшего.
По иному в этом плане выглядит ReiserFS — не смотря на затраты ресурсов при ведении журнала, по быстродействию она не очень отличается от ext2fs.
А на некоторых операциях (например, копировании большого количества мелких файлов — согласитесь, достаточно частая пользовательская задача) так и оставляет старушку позади. Кроме того, ReiserFS обладает уникальной (и по умолчанию задействованной) возможностью оптимизации дискового пространства, занимаемого мелкими (менее одного дискового блока) файлами (а в любом UNIX таких файлов величайшие множества): они целиком хранятся в области метаданных.
А «хвосты» (конечные части файлов, меньшие, чем один блок) могут быть подвергнуты упаковке, и это — тоже умолчальная ее фича. Правда, ReiserFS не совместима с ext2fs на уровне обслуживающих утилит, но соответствующий инструментарий уже давно включается в штатный комплект современных дистрибутивов.
Оборотная сторона медали: распространенные загрузчики Linux (и Lilo, и GRUB) часто не способны загрузить ядро Linux с раздела ReiserFS, оптимизированного в отношении объема. Как обычно бывает в Linux, этот режим можно отключить, что приведет еще и к росту быстродействия.
Однако следует учесть — после пересборки ядра умолчальные возможности оптимизации будут задействованы вновь. И в результате пользователь, перед которым со временем возникла потребность в перекомпиляции ядра (а поверьте, это произойдет с фатальной неотвратимостью), может с удивлением обнаружить, что правильно собранное им ядро отказывается загружаться (я с такой ситуацией сталкивался и был поначалу обескуражен, пока не понял, в чем дело). Именно поэтому создание отдельного раздела под каталог /boot может быть необходимым.
И, наконец, XFS. В отличие от прочих, порожденных миром свободного софта (ReiserFS — творение Ханса Райзера, немца, рискнувшего выбрать для ПМЖ и работы наше отечество, а ext3fs — создана в Red Hat), эта файловая система пришла от проприетарных «юниксов» (конкретно — из компании SCI, в коей давно уже разрабатывалась для собственной ОС Irix).
Однако ныне это такой же Open Sources, что и другие, условия лицензирования которого не вызовут претензий у самого строгого ГНУ-пуриста.
Чем же она, XFS, замечательна? В первую очередь, сбалансированностью: за счет хитрого механизма журналирования она почти столь же надежна, как ext3fs, и не очень уступает ReiserFS в быстродействии на большинстве файловых операций. Ну и собственная коронка — работа с (очень) большими файлами.
Здесь XFS держит прочное первенство по быстродействию: как легко догадаться по ее родословной, именно под работу с мультимедийными файлами она и затачивалась. Имеет XFS и еще некоторые маленькие, но приятные особенности, типа расширенной атрибутики файлов.
Некоторый недостаток ее — низкая скорость удаления файлов; но, хотелось бы верить, мало кому потребуется тотально стирать гигабайты данных. Если же вспомнить, что никто и нигде не упоминал о проблемах совместимости XFS — она становится первым кандидатом на титул абсолютной файловой системы, не так ли?
Так оно и было бы, если б не очередное пятно на солнце: в отличие от ReiserFS и ext2fs, штатно встраиваемых в ядро Linux (начиная с версий 2.4.4 и 2.4.16, если не ошибаюсь, соответственно), XFS по сию пору не поддерживается каноническим ядром «Линуса» (тем самым, которое можно получить с http://www.kernel.org/).
Конечно, обеспечить поддержку XFS можно посредством патча с SGI’s XFS page (здесь же берется и инструментарий для работы с XFS — традиционный, рассчитанный на ext2fs, для нее также не пригоден), а некоторые дистрибутивы уже комплектуются соответствующим ядром.
Однако при предварительной разметке диска о такой возможности следует помнить.
Подведем итог: каждая из четырех рассмотренных файловых систем имеет свою уникальную положительную особенность (даже ext2fs — как бы то ни было, лидером по суммарному быстродействию остается она) и как минимум один недостаток (который, тем не менее, не служит препятствием к ее использованию). И потому любая из наших героинь заслуживает почетного места на десктопе пользователя.
Практическая интермедия
Надеюсь, предыдущий раздел дал вдоволь информации к размышлению на тему: а какая же файловая система подойдет именно мне? Не предугадывая ответа, намечу порядок действий в каждом из возможных случаев.
В принципе при установке дистрибутива Linux создание файловых систем — компетенция инсталлятора, который далеко не всегда допускает ручное вмешательство пользователя.
Однако создает он файловые системы с некоторыми умолчальными характеристиками, не всегда лучшими с точки зрения быстродействия. А изменить их без переформатирования (влекущего, понятно, потерю данных) нет ни малейшей возможности. Так что если в программе установки возможность ручного вмешательства предусмотрена — иногда имеет смысл ею воспользоваться.
Если нет желания ломать голову над сравнительными достоинствами, для пользовательского десктопа (а о серверах у нас речи нет) ext2fs остается нормальным выбором для всех разделов. Она может быть создана любой из следующих команд — /sbin/mke2fs, /sbin/mkfs, /sbin/mkfs.ext2 с указанием файла устройства в качестве аргумента, например:
$ /sbin/mke2fs /dev/hda1.
Каждая из этих команд имеет некоторые опции, однако обычно необходимости в них не возникает.
Для создания файловой системы ext3fs можно применить ту же команду mke2fs с опцией -j или специальную команду mkfs.ext3. Замечу, что можно и преобразовать в нее ранее созданную ext2fs — не только без потери данных, но и без перезапуска системы.
Да и избавление от журнала (то есть откат к первозданной ext2fs) — процедура ничуть не более сложная.
Файловая система ReiserFS создается предназначенной для этого командой — /sbin/mkreiserfs. И во избежание уже упомянутых неожиданностей (и которые потому неожиданностями быть не должны), напомню: если корневой раздел форматируется как ReiserFS, совсем не худо предусмотреть небольшой раздел под каталог /boot и разместить на нем файловую систему ext2fs, от которой неожиданностей ждать не приходится.
Аналогично и XFS — для ее создания существует собственная команда mkfs.xfs.
Однако (и это тот самый случай, который я имел в виду в начале раздела) для достижения максимальной производительности она может применяться с некоторыми опциями: $ -d agcount=# -l size=##m /dev/hda1,где # и ## — численные значения соответствующих опций.
Значение первой указывает на число allocation group (тот самый хитрый механизм XFS, о котором я упоминал выше) и выбирается из расчета: одна группа на 4 Гб объема раздела с округлением в большую сторону. А опция -l size устанавливает ограничение на объем журнала (m — в мегабайтах), рекомендованное значение — 32 Мб.
Монтировочный финал
Вот и все, файловые системы созданы. Дело осталось за малым — сделать их доступными для операционной системы ну и, естественно, для пользователя. Это достигается выполнением операции монтирования, то есть включения в общую структуру каталогов — ведь мы помним, что любой файл получает имя только в составе каталога верхнего уровня.
Сейчас не место и не время вдаваться в детали иерархии каталогов. Тем более, что в большинстве дистрибутивов за монтирование файловых систем отвечает их собственный инсталлятор, который, как и в случае с файловыми системами, не обязан приветствовать вмешательство пользователя.
И хотя он также не всегда действует идеально — не беда: уж тут-то любые умолчальные недоработки легко могут быть исправлены в последующем. Так что буду предельно краток.
Монтирование осуществляется командой mount, требующей двух аргументов — имени монтируемого устройства (сиречь раздела) и точки монтирования. Не худо, хотя обычно и не обязательно, указать также тип монтируемой файловой системы посредством соответствующей опции. То есть в общем случае это будет выглядеть так: $ mount -t ext3fs /dev/hd?# /mount_point.
Из всего упомянутого мы не затрагивали только понятие точки монтирования. Суть очень проста: это каталог корневой файловой системы, к которому приписывается содержимое файловой системы монтируемой. Что легко понять, вспомнив о многократно поминаемых ранее разделах для грядущих каталогов /, /boot, /home и прочих.
Каталог, в который монтируется файловая система, должен быть создан заблаговременно и желательно пустым: монтирование в каталог с файлами ныне фатальных последствий не повлечет, но все его содержимое станет недоступным.
Очевидно также, что первым должен монтироваться корневой каталог (/), поскольку и /boot, и /home, и /usr и прочие представляют собой ветви на его древе. Собственно, свои имена (/boot etc.) они и обретут только после монтирования.
И здесь возникнет вопрос — как же монтировать раздел, зарезервированный под корневой, к уже существующему корневому разделу. Или, хуже того, к корневому разделу системы, которая еще не инсталлирована. Нет ли здесь противоречия? Его действительно нет. Вернее, оно не учитывается — ибо установщик ОС Linux работает под управлением ее же самой.
И система, управляющая программой установки, обязана иметь многие атрибуты полноценной операционки, в том числе, и корневую файловую систему. Другое дело, что базируется она не на каком-либо дисковом устройстве — таковое может в начале инсталляции сохранять девственную чистоту, а в оперативной памяти (я не зря упомянул в преамбуле RAM-disk). И наш новый раздел, которому суждено стать корневым, монтируется в некий каталог этой самой виртуальной корневой файловой системы.
Возможно, все сказанное по первости не очень понятно. Но к вопросу смены корневого каталога я надеюсь еще вернуться — когда мы попробуем установить систему с нуля, опираясь на материалы этих (и еще нескольких последующих) заметок. А пока, подобно поручику Ржевскому — прошу поверить на слово.
И, главное, вспомнить, что наша сиюминутная цель — просто проиллюстрировать, что же скрывается за графическими красотами инсталляторов операционки Red Hat или соплеменной ей Mandrake, когда нам предлагается щелкнуть на метафоре диска с целью его реорганизации под Linux.
Те, кто подобные дистрибутивы устанавливал, думаю, меня уже поняли…
