12 лет назад 17 октября 2006 в 12:37 85

Необходимая преамбула

Понятие файловой системы – одно из самых многозначных в околокомпьютерной терминологии; больше значений имеет, пожалуй, только просто слово “система”. Во-первых, файловая система – это система устройства файлов как таковых: в этом аспекте говорят о файловой системе 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.

Те, кто подобные дистрибутивы устанавливал, думаю, меня уже поняли… 

Никто не прокомментировал материал. Есть мысли?