Freebsd какую файловую систему выбрать. Настройка автоматического монтирования. Подробная инструкция с пояснениями

Алексей Федорчук
2004-2005 гг

В настоящей заметке речь пойдет о способе физической организации блоков дискового раздела, обеспечивающем возможность записи, хранения и манипулирования файлами, специфичном для FreBSD, точнее, для её файловых систем UFS и UFS2, бывших единственно нативными в этой ОС до портирования ZFS.

Вступление

Файловая система FreeBSD принадлежит к Unix-семейству файловых систем и обладает множеством общих для всех них черт. Она носит название UFS, в 5-й ветке используется ее усовершенствованная разновидность — UFS2. Для начала рассмотрим общие принципы устройства той и другой, а потом обратимся к рассмотрению особенностей, свойственных UFS2.

Для файловой системы FreeBSD (и вообще BSD-систем, начиная с 4.2BSD) можно встретить и еще одно наименование — FFS (Fast File System). Для понимания соотносимости этих терминов необходимо обратиться к истории…

Изначальная файловая система Unix носила имя s5fs (то есть файловая система System V). По свидетельству современников, была она отменно медленной, да еще и не допускала имен файлов из более чем 14 символов. А поскольку в те времена в Университете Беркли также разрабатвалась версия Unix (именовавшаяся BSD Unix — предтеча всех современных BSD-систем), то решили поправить дело. И создали файловую систему, названную FFS (где Fast означало ее быстроту сравнительно с s5fs).

Поскольку разработки Берклианцев изначально (еще до того, как RMS придумал Open Sources и Free Software Foundation) были свободными, разработчики первозданного Unix’а не погнушались включить поддержку FFS в очередную версию канонической System V. А уже от нее и произошло большинство современных файловых систем Unix’ов, как проприетарных, так и свободных. И UFS — одна из таких реализаций, включающей элементы виртуальной файловой системы, vfs/vnode (по крайней мере, именно так трактует эти понятия Ю.Вахалия в своей книге «Unix изнутри»). А UFS2, как легко догадаться, — усовершнествованная 64-разрядная версия последней.

Хотя вообще говоря, UFS расшифровывается просто как файловая система Unix (Unix File System). И под этим именем известны и файловые системы других ОС этого семейства, отнюдь не идентичные UFS из FreeBSD. Так что некоторая неопределенность терминологии имеет место быть…

Как было выяснено в , логический дисковый раздел (часть слайса) — это, говоря метафорически, группа смежных цилиндров, разбитых на физические блоки по 512 байт. Однако специфика файловых систем BSD-клана заключается в том, что реально она делится еще и на части фиксированного объёма (зависящего от объема раздела). Это т.н. группы цилиндров (условно назовем ее внутренней), каждая из которых имеет включает четыре самостоятельные части:

суперблок, идентичный по содержанию для всех групп;
блок группы цилиндров, оную описывающий; одной из важнейших его частей является
индексная таблица (или таблица inodes );
область блоков данных.

Рассмотрение их целесообразно начать с конца списка, то есть с области данных.

Блоки данных

Область данных (она занимает подавляющий объем пространства каждой группы цилиндров) образована блоками файловой системы. Подобно физическому блоку, блок файловой системы (именуемый также блоком логическим) представляет собой квант информации, доступный за одну операцию чтения/записи, но уже не дисковой головки, а операционной системы. Очевидно, что логический блок не может быть меньше блока физического (то есть 512 байт), и размер его обязательно кратен целому числу последних.

Понятие логического блока введено для повышения производительности дисковых операций. Не требует доказательства утверждение, что скорость обмена данными квантами по 1 Кбайт будет выше, чем 512-байтными, 2-килобайтными — еще быстрее, и так далее. И потому с точки зрения быстродействия файловых операций выгоден максимальный размер логического блока файловой системы.

С другой стороны, увеличение размера логического блока ведет к непроизводительному расходу дискового пространства за счет т.н. внутренней фрагментации данных. Ее не следует путать с внешней фрагментацией, для борьбы с которой на файловых системах FAT-семейства были в свое время мобилизованы всякого рода speeddisk’и с комбатантами: вследствие особенностей алгоритмов управления данными файловые системы Unix-семейства настолько мало подвержены внешней фрагментации, что о преодолении оной вообще практически не говорят.

Внутренняя же фрагментация выражается в том, что данные файлов, размер которых меньше блока файловой системы, все равно занимают его целиком. Также целый блок потребуется и для хранения файловых хвостов, то есть остатков сверх объема, кратного размеру логического блока. Для борьбы с фрагментацией в UFS, пардон за тавтологию, введено понятие фрагмента — логической части блока файловой системы, которая может быть записана или считана независимо от остальной его части.

Ясно, что размер фрагмента все равно не может быть меньше физического блока. При этом UFS накладывает на него и встречное ограничение — минимальный размер фрагмента определяется в 1/8 логического блока. Другие же возможные значения — 1/4 и 1/2 блока файловой системы (очевидно, что выделение фрагмента в размере блока равносильно отказу от фрагментации блока вообще, хотя это, как будто бы, не запрещено).

Inodes

Каким образом определяется принадлежность блока данных тому или иному файлу? К помощью индексной таблицы, именуемой также таблицей индексных дескрипторов или таблицей inodes . Она образована некоторым (конечным) количеством записей фиксированной длины (128 байт в UFS, 256 — в UFS2), каждая из которых однозначно соответствует одному файлу, как реально существующему, так и только могущему быть созданным.

Такая запись индексной таблицы носит название inode , которое мы и оставим за нею. Ибо все известные мне переводы этого термина, вроде информационных узлов или индексных дескрипторов, выглядят очень коряво. Кроме того, слово «дескриптор» фигурирует еще и в контексте «дескриптор файла», под чем подразумевается идентификатор (уникальный, иначе что же он будет идентифицировать?) файла, используемого неким процессом (что уже к файловым системам не имеет ни малейшего отношения — это сфера подсистемы управления процессами). И эти дескрипторы — не имеют меж собой ничего общего. Так, inode c идентификатором 2 (а это всегда идентификатор корневого каталога файловой системы) и дескриптор файла с номером 2 (а им для любого процесса будет стандартное устройство вывода сообщений об ошибках, /dev/stderr) ни коим образом друг с другом не соотносятся (хотя об этом почему-то не любят говорить вслух).

Однако я отвлекся — вернемся к нашим inodes . Каждый член этой таблицы содержит так называемые метаданные файла. Для реально существующего файла они включают в себя:

уникальный идентификатор inode (и, соответственно, файла, метаданные которого он содержит) — это просто счетчик создаваемых файлов в файловой системе);
тип файла — это может быть каталог, символическая ссылка, файл устройства, именованный канал или сокет, или же обычный (то есть не относящийся ни к какому из перечисленных типов) файл;
размер файла в байтах;
количество ссылок на файл (к этому вопросу придется вернуться чуть ниже);
адреса логических блоков и их фрагментов, составляющих файл;
число занятых им блоков;
атрибуты файла — принадлежности, доступа, режима, времени.

А вот чего в inode не обнаружить никакими силами — так это имени соответствующего ему (или ей? — мне почем-то кажется, что inode , вопреки грамматике, — женского рода). В любой книжке про Unix не устают повторять (и я не отступлю от этой доброй традиции), что имя файла — не атрибут самого файла, а элемент каталога, в который он входит. Поскольку понимание этого потребуется вскоре при знакомстве с механизмом Soft Updates, сделаю маленькое отступление для прояснения вопроса именования файлов во FreeBSD (и вообще в Unix).

При описании содержания таблицы inodes вскользь было упомянуто поле типа файла. Так вот, в Unix все файлы (а все, что в Unix имеется вообще, включая физические устройства, для системы представляется в виде файлов) делятся на две группы — каталоги и прочие. Прочие файлы могут служить для различных целей (хранения данных и исполняемых программ, быть символическими ссылками, описывать устройства или средства взаимодействия процессов). Назначение же каталогов — единственное, но оченно важное: быть хранителями имен входящих в них файлов, которым однозначно поставлены в соответствие идентификаторы inodes , хранящих метаданные этих файлов.

То есть имя файла существует только в списке каталога и нигде более в системе. А создание файла — это не только заполнение относящейся к нему записи в индексной таблице и заполнение указанных в ней блоков данных, но и внесение записи вида «идентификатор — имя_файла» в область данных какого-либо каталога. А каталог, как и любые другие файлы, имеет свои метаданные в таблице inodes и свою область данных. И, в свою очередь, имя его вместе с идентификатором inode входит в каталог более высокого уровня, и так — вплоть до корня файловой системы. В поле количества ссылок inode создаваемого файла устанавливается минимально возможное значение, равное единице, поскольку любой файл входит по меньшей мере в один каталог, иначе он просто не будет доступен системе — файлы с нулевым количеством ссылок для нее как бы не существуют (и на самом деле их inodes и блоки данных со временем неизбежно будут перезаписаны физически; если, конечно, файл не был открыт в какой-либо программе — в этом случае он будет сущестовать, даже если имя его удалено из всех каталогов).

На самом деле один и тот же набор данных и метаданных может быть приписан к произвольному количеству каталогов в пределах одной файловой системы и даже фигурировать под разными именами в одном каталоге — в этом случае количество ссылок на него будет соответствующим. А вот минимальное количество ссылок на каталог равно двум — так как запись о нем существует как в родительском каталоге (..), так и в текущем (. — то есть в самом себе). И каждый вложенный подкаталог увеличивает счетчик ссылок каталога на единицу.

Ссылки, с помощью которых связывается имя файла как элемент каталога с его записью в таблице inodes и блоками образующих файл данных, именуются еще жесткими (hardlinks, хорошим русскоязычным эквивалентом было бы слово «связь», но оно как-то не прижилось). Посредством жестких ссылок одному и тому же набору данных или исполняемой программе можно придать произвольное количество имен, которые никто не запрещает включить в один и тот же или разные каталоги. Единственное условие для этого — все эти имена-дублеры должны находиться в каталогах единой файловой системы (фигурально говоря, на одной дисковой партиции, хотя, как это будет показано в разделе о программном RAID’е, это не совсем точно).

Определенности ради отмечу, что жесткие ссылки нужно отличать от ссылок символических (symlinks, часто говорят просто links — почему и резонно было бы сохранит за ними обозначение ссылок, а hardlinks по русски именовать связями). Символические ссылки — файлы особого типа, отдаленно сходные с ярлыками в Windows или shadow в OS/2, которые сами по себе никаких данных не содержат, а просто описывают путь к имени другого файла (который может локализоваться и за пределами данной файловой системы).

Для файлов несуществующих свободные записи в таблице inodes просто резервируются. А поскольку количество этих записей — конечно, именно объем индексной таблицы и определяет, сколько файлов реально может быть создано в данной файловой системе. Исчерпание свободных записей в ней приводит к тому, что, вне зависимости от объема свободного дискового пространства, ни одного нового файла создать не удастся.

Блок группы цилиндров и суперблок

Таблицы inodes содержатся в блоке группы цилиндров, наряду с картами свободных/занятых inodes и карты свободных/занятых блоков данных). Это имеет целью размещение inodes и относящихся к ним блоков данных максимально близко друг к другу, что, кроме повышения производительности (за счет минимизации перемещений головок), влечет за собой и сведение к минимуму той самой внешней фрагментации данных, о которой говорилось выше.

Однако сведений об объеме индексной таблицы в блоке группы цилиндров не обнаруживается. Ибо место их размещения — тот самый суперблок, который идет первым в нашей партиции (вообще-то первым в любой партиции будет загрузочный блок, но реально он занят только в загрузочном же разделе — во всех остальных для него просто зарезервировано место). А также дублируется в каждой группе цилиндров — чем обеспечивается устойчивость к механическим повреждениям диска. Кроме этого, в суперблоке же записывается размер блока файловой системы и их суммарное количество, число блоков данных, размер блокового фрагмента и их число в блоке, число блоков, реально занятых файлами, объем партиции, перманентно резервируемый как свободный, и еще множество характеристик файловой системы, о которых сейчас говорить неуместно.

Практика форматирования

Таким образом, процесс создания файловой системы сводится к а) выделению суперблока и записи общих параметров файловой системы, б) созданию таблицы inodes (в UFS, в отличие от некоторых современных файловых систем для Linux, все inode создаются раз и навсегда, а не выделяются динамически, по мере надобности), и в) разметке блоков в области данных. Из за все это, подобно незабвенной Катерине Матвевне, отвечает одна-единственная программа, именуемая незамысловато — newfs .

Команда newfs требует единственного аргумента — имени файла форматируемой партиции, например,

$ newfs /dev/ad0s1a

после чего все базовые свойства файловой системы будут определены по умолчанию. Однако пользователь в силах влиять на них с помощью опций команды newfs , задаваемых в командной строке или раз и навсегда глобально, через пункт Options программы sysinstall . Важнейшие из этих опций мы и рассмотрим,

Опция -b определяет размер логического блока файловой системы. Минимальный размер его — 4096 байт, максимальный — 65536. Однако, как говорят, при максимально возможном размере возможны всякие неприятности, и потому надежным считается верхнее ограничение в 32768 байта. А с точки зрения здравого смысла, «умолчальное» значение в 16384 байт представляется в большинстве случаев разумным.

Опция -f устанавливает размер фрагмента блока. Рекомендуется определить его в 1/8 размера блока, что по умолчанию и составит 2048 байта. Значения в 1/4 или 1/2 блока также допустимы, но очень не рекомендуются в документации.

Опция -i очень важна — она-то косвенно и устанавливает количество записей в индексной таблице (то есть максимальное количество файлов в файловой системе). Значение этой опции дается в байтах, отводимых на элемент индексной таблицы, и должно быть кратным размеру блокового фрагмента. Значение по умолчанию — учетверенный объем оного, что определяет средний прогнозируемый размер файла (8192 байт). А максимальное количество файлов в конкретной файловой системе легко рассчитать, исходя из объема отведенного под нее раздела.

Еще одна интересная опция — это -m , значение которой указывается в процентах от суммарного объема дискового пространства, отведенного на раздел. И представляет собой объем, резервируемый от записи обычными пользователями (но не root’ом — тот всегда имеет возможность записать свои действия на диск). Он определяется потому, что быстродействие файловых операций в UFS просто катастрофически падает, когда количество свободных блоков в области данных близко к исчерпанию (проверено на практике). И потому некий объем файловой системы резервируется принудительно (по умолчанию — 8%).

С этой опцией связана еще одна, -o , которая определяет алгоритм выделения свободных блоков данных при создании новых файлов. Дело в том, что UFS в состоянии размещать их двумя способами. Первый — методом плотнейшей упаковки с целью минимизации внутренней фрагментации и экономии дискового пространства. И называется он оптимизацией по объему (опция -o принимает значение space). Второй же метод (-o time) обеспечивает быстрейшее выделение свободных блоков с целью увеличения скорости создания файлов (то есть вопреки принципу Леонида Ильича Брежнева — «экономика должна быть экономной»). Так вот, умолчальное значение -o коррелирует со значением -m: если оно больше или равно 8%, применяется оптимизация по времени, если меньше — по объему. Хотя явным образом можно указать прямо противоположные значения.

Вообще-то, все приведенные выше опции очень важны, интересны и полезны для общего образования, однако пользователю вряд ли придется к ним прибегать: их значения по умолчанию, как и почти все во FreeBSD, разумны и приемлемы в подавляющем большинстве случаев. А вот опция -U при запуске newfs по умолчанию не задействуется. Обеспечивает же она поддержку штуки крайне полезной — механизма Soft Updates, способствующему (парадоксально, но — правда) как повышению быстродействия файловых операций, так и устойчивости файловой системы.

Тема Soft Updates, однако, столь интересна сама по себе, что заслуживает отдельного обсуждения, чем мы и займемся в следующем разделе. А пока под рассмотрим отличия текущей разновидности файловой системы FreeBSD, UFS2, от ее предшественницы — UFS.

Все, что было сказано выше о файловой системе FreeBSD, относилось в равной мере к обеим ее разновидностям. Главная особенность UFS2 — то, что она 64-разрядная и, соответственно, способна работать с дисковыми объемами более терабайта (интересно, скоро это станет актуальным для настольного пользователя? Судя по темпам дискобольства, срок этот не за горами). В этой связи напомню, что длина записи в таблице inodes в UFS2 удвоилась, и равна 256 байт.

Далее, в UFS2 включена поддержка расширенных атрибутов файлов, в частности, ACL, но это существенно для сетевых администраторов. А вот что может заметить пользователь — то, что создание новой файловой системы происходит быстрее (на больших дисковых разделах это действительно заметно, что называется, органолептически). Происходит это за счет т.н. «ленивой» инициализации inodes , хотя динамического их выделения, как, например, в XFS, и нету.

А вообще, с точки зрения пользователя, различий между UFS и UFS2 можно и не увидеть. Тем не менее, отказываться от UFS2 также оснований нет. Тем более, что и newfs , о которой говорилось выше, и sysinstall по умолчанию ныне (в 5-й ветке) создают именно ее. Если же требуется создать просто UFS (для совместимости с версиями прежних веток, UFS2 не поддерживающих), это нужно сделать принудительно, указав для newfs опцию -O 1 .

Парадокс Soft Updates

При всех своих многочисленных достоинствах, файловая система FreBSD не может похвастаться одним — быстродействием. И это не смотря на то, что в основе ее лежит обще-берклианская FFS — быстрая файловая система. Однако эпитет здесь выступает в сравнении с прежней Unix’овой файловой системой — s5, все вариации которой, как говорят знающие люди, отличались исключительной задумчивостью. Если же сравнить производительность файловой системы FreeBSD с родной для Linux Ext2fs — перед пользователем она предстанет существенно более медленной, чем последняя, особенно на операциях с большим количеством мелких файлов.

Почему? Нетрудно ответить: вследствие принятого во FreeBSD по умолчанию режима обращения с измененными файлами. Большинство нормальных файловых систем способны функционировать в одном из трех режимов:

полностью синхронном, когда обновления и метаданных, и области данных файла записываются на диск сразу вслед за его изменением;
полностью асинхронном, при котором все изменения файла (и его метаданных, и области данных) кэшируются в оперативной памяти и реально записываются на диск в подходящее для того время;
смешанном, реализующем синхронный механизм для измененных метаданных и кэширование — для модификаций области данных.

Очевидно, что первый режим обеспечивает наибольшую устойчивость файловой системы к сбоям, второй — наибольшее быстродействие файловых операций (ценой возможности нарушения целостности файловой системы и даже полного ее разрушения при аварийном завершении работы), а третий представляет собой как бы компромисс между первым и вторым решением.

Так вот, в файловой системе Linux (конкретно — в ext2fs, Linux нынче за родные признает много файловых систем) по умолчанию задействуется полностью асинхронный режим работы, а во FreeBSD — смешанный. Конечно, это определяется при монтировании файловых систем, и с помощью соответствующих опций команды mount (что я покажу в соответствующей заметке) файловую систему FreeBSD можно заставить работать полностью асинхронно. Однако резонные люди не рекомендуют это делать категорически — и, вероятно, имеют к тому основания (одна из причин к тому станет ясной в конце этого раздела). Да и, как следует из тестов, существенного прироста быстродействия асинхронное монтрование файловых систем во FreeBSD не дает.

И действительно, в умолчальном режиме файловая система FreeBSD (в сравнении с той же ext2fs) демонстрирует замечательную устойчивость. За годы общения с этой ОС (а из которых половина пришлась на селянские условия, когда неожиданное отключение электричества было вещью более чем обычной) мне ни разу не пришлось столкнуться с проблемами из-за аварийного завершения сеанса работы (в Linux’е такие проблемы, до внедрения журналируемых файловых систем, возникали сплошь и рядом).

Однако цена за это — быстродействие. Вернее, отсутствие оного. И проявляется это особенно наглядно именно при копировании большого количества мелких файлов (процедура, весьма обычная при работе с текстовыми, по преимуществу, материалами). Действительно, при этом в синхронном режиме обновляется огромное количество файловых inodes , тогда как собственно данных изменяется ничтожное по объему количество, и их кэширование доставляет мало радости. В любом случае копирование набранных в текстовом редакторе статеюшечек размером с эту заметку и суммарным объемом в стандартный CD затягивается на вполне чувствительное время (в отличие от Linux’а, где подобная операция выполняется внешне мгновенно — другое дело, что индикатор активности жесткого диска может еще долго подмигивать).

Далее, не смотря на всю свою фактическую устойчивость, файловая система FreeBSD, не будучи журналируемой, сама по себе не имеет механизма гарантии собственной целостности. То есть: при аварийном завершении работы, когда в файловой системе не устанавливается т.н. бит чистого размонтирования (clean byte — это один из важных параметров файловой системы, записываемый в ее суперблоке при корректном выходе из системы), в ходе процедуры последующей загрузки принудительно вызывается программа проверки ее на предмет нахождения противоречий между метаданными и областями данных (и их устранения). А при современных объемах дисков (и, соответственно, файловых систем на них) такая проверка может затянуться на часы. Конечно, это особенно прискорбно для серверов, но и на настольной машине доставляет мало положительных эмоций.

Проблема нарушения целостности существует и в Linux’е (по указанным выше причинам — даже в большей мере). И в Linux’е с нею борются посредством журналирования, то есть опережающей регистрации изменений метаданных (и, в некоторых случаях, даже и данных). Во FreeBSD же борьба за целостность файловой системы велась исторически по двум направлениям. Одно из них (хотя исторически и второе) — появившаяся в 5-й ветке фоновая проверка целостности файловой системы, допускающая начало нормальной работы сразу после аварийной перезагрузки машины. Поскольку это — одно из принципиальных новшество, скажу пару слов по сему поводу.

Для проверки целостности файловой системы во FreeBSD используется утилита fsck (одноименная есть и в Linux — для ext2fs, есть аналогичные инструменты и для прочих файловых систем). Она может быть запущена пользователем (вернее, root’ом) из командной строки. Однако схема старта системы предусматривает ее принудительный запуск, если в какой-либо из автоматически монтируемых файловых систем не обнаружен бит чистого размонтирования. А поскольку fsck — побитная операция, во избежание тяжких последствий она обычно проводится на размонтированных файловых системах.

Так было и во FreeBSD вплоть до версий 4-й ветки. А вот в версиях 5-й ветки, начиная с первой, проверка диска может выполняться на смонтированной и готовой к работе файловой системе. И, соответственно, в фоновом режиме после полной загрузки системы, параллельно с выполнением обычной работы. Казалось бы — пустячок, а приятно: затрудняюсь сказать, сколько заняла бы полная проверка обычных ныне 80- или 120-гигабайтных винтов.

Однако первым по времени реализации способом борьбы за целостность файловой системы был механизм Soft Updates, обеспечивающий одновременно (вернее, главным образом) и повышение быстродействия файловых операций.

Сам по себе механизм Soft Updates описан далее. В двух же словах суть этого механизма — в сведении к минимуму синхронных операций записи без явно асинхронного манипулирования метаданными, с одной стороны, но и без предварительного журналирования метаданных (как в файловых системах типа ReiserFS или XFS) — с другой.

Реализуется это, опять же говоря довольно грубо (детали реализации моему пониманию недоступны — каюсь) за счет так называемых зависимостей обновления. Что такое эти зависимости — интуитивно ясно из примера создания нового (для простоты — пустого) файла. Для этого требуется:

запись в таблице inodes , с заполнением полей типа файла, его идентификатора, счетчика ссылок (со значением 1 — каждый файл должен принадлежать как минимум одному каталогу), ну и прочих там — прав доступа в соответствие с умолчальной маской, и так далее;
изменение карты свободных/занятых inodes в блоке группы цилиндров (соответствующий новому файлу inode должен быть помечен в ней битом занятости);
внесение записи вида «идентификатор — имя_файла» в структуру каталога, в котором новый файл создается, что обеспечивает ту самую единственную ссылку в соответствующем поле inode файла.

С точки зрения целостности файловой системы, эти операции должны быть выполнены именно в этой последовательности. То есть наличие в каталоге имени файла с идентификатором незаполненного (еще не созданного или уже уничтоженного) inode — явный непорядок: именно для исправления такого рода безобразий и запускается программа проверки диска после аварийного завершения сеанса.

Выполнять связанные зависимостями операции обновления в синхронном режиме — долго (каждая потребует своего обращения к диску), в асинхронном — нет гарантии сохранения последовательности (обновления в кэше могут быть записаны тогда, когда бог на душу положит). Так вот, механизм Soft Updates обеспечивает, с одной стороны, контроль за последовательностью выполнения зависимых обновлений (что способствует целостности состояния файловой системы), с другой — группирует их в единую атомарную операцию синхронного обращения к диску, за счет сокращения числа коих и растет производительность. В этом, насколько я понимаю, и состоит объяснение парадокса Soft Updates — неожиданного увеличения и надежности, и быстродействия.

В общем, постарался объяснить, как смог и как сам понял — за подробностями к упомянутой статье. В дополнение только замечу — во избежание недоразумений: механизм Soft Updates не только не гарантирует сохранности пользовательских данных, не записанных на диск по раздолбайству юзера перед крахом системы, но и не преследует такой цели. Его призвание — следить, чтобы файловая система всегда представала по возможности в непротиворечивом виде. Впрочем, то же можно сказать и о любой журналируемой файловой системе — ни одна из них не страхует от ошибок пользователя…

Теперь посмотрим, как же Soft Updates можно использовать. Если создавать файловые системы через sysinstall — все просто: там по умолчанию включение этого механизма уже давно (версии примерно с 4.3) предусмотрено для всех файловых систем, кроме корневой. Последнее аргументируется соображениями безопасности. Да и для корневой файловой системы Soft Updates не особо нужна: при правильном разбиении диска и грамотной эксплуатации запись в нее (после первичной установки) происходит только при инсталляции нового ядра, а часто ли это проделывается в нормальных условиях?

При создании же файловых систем вручную, командой newfs , Soft Updates автоматически не включается: это нужно сделать, как уже говорилось, указанием опции:

$ newfs -U /dev/ad#s#?

Впрочем, если она при форматировании была забыта — ничего страшного: для всех разделов, кроме корневого, включить Soft Updates легко с помощью команды tunefs . Для этого следует перейти в однопользовательский режим (очень рекомендуется; я как-то обошелся без этого, но лучше следовать советам резонных людей), что делается командой

$ shutdown now

Размонтировать все файловые системы, кроме корневой (с ней все равно этот номер не пройдет) командой

$ umount -Af

Дать команду

$ tunefs -n enable /dev/ad#s#?

для каждого раздела, в файловой системе которого требуется Soft Updates. И, наконец, повторением команды

Часто обращаю внимание на то, что простые вопросы чаще всего мало освещены в интернете. Наверное, это потому, что все гуру уверены, что никто никогда не задаст таких глупых вопросов, ведь это знает каждый. Но моя практика показала, что именно такие мелкие простые вопросы самые частые не только у новичков, а и у серьезных администраторов, которым просто не приходилось иметь с этим дела. Даже серьезные администраторы не делают это каждый день, а, чтобы не забыть, ведут некую шпаргалку для себя, никому в этом не признаваясь. Давайте все исправим. Сейчас Вы узнаете, как за 5 минут добавить жесткий диск в FreeBSD. Итак. Сначала будет преведена полная инструкция для понимания процесса, а в конце будет краткий список действий , которое будет содержать лишь список команд в качестве шпаргалки.

Подробная инструкция с пояснениями

Выбор имени жесткого диска

Для начала нужно определить имя устройства, которое мы только что добавили. В этом нам поможет следующая команда:

Geom disk list

Или же вот такая команда:

Camcontrol devlist

В реальной системе эти команды покажут более полезную информацию, а именно: названия устройств и их серийные номера.

До установки нового устройства мы знали, что наша система установлена на ada0, значит по логике вещей наш новый диск ada1. Это вы можете определить по названию нового устройства, его серийному номеру или же объему.

Теперь проверим, имеется ли разметка на нашем новом диске

Gpart show ada1

Диск не имеет никакой разметки.

Удаление существующей разметки

Если диск уже использовался и есть необходимость удалить с него разметку, просто выполните:

Gpart destroy -F ada1

Создание разметки GPT

Для начала мы должны создать разметку диска. Крайне рекомендую забыть о MBR и перейти на новую, более удобную и функциональную - GPT.

Создаем разметку GPT на диске, затем проверяем, что вышло:

Gpart create -s gpt /dev/ada1 gpart show ada1

Теперь у нас диск имеет разметку GPT. Из вывода можно увидеть, что абсолютно весь диск, начиная с LBA 34 и заканчивая LBA 8388541 пуст. LBA 0−33 - зарезервированы системой под таблицу разделов.

Допустим, нам необходимо создать два раздела на этом диске:

swap - раздел подкачки
data - раздел типа ufs для хранения каких либо, необходимых нам, данных.

Создание разделов (слайсов)

Если установка производится на современные жесткие диски, у которых размер сектора = 4 кб, то при создании разделов (партиций) необходимо использовать выравнивание. Можно поступить двумя способами: 1) если указываем параметры раздела в блоках, то номер блока вводить кратным 8, например: -b 40 ; 2) если указываем размер раздела в байтах, либо не указываем вообще начало и размер, использовать параметр -a 4k , который подгонит начало и конец раздела под секторы, размером 4 кб. Так как мы в данном примере производим тестовую установку на виртуальный жесткий диск, то этого можно не делать. В любом случае перед созданием разделов нужно точно знать размер сектора вашего накопителя, иначе это выльется жуткими тормозами в работе.

Теперь создадим разделы. Для этого существует команда gpart add с различными параметрами. Первый параметр -t - указывает на тип создаваемой файловой системы. В нашем случае будет использовано два типа: freebsd-swap и freebsd-ufs. Далее идут два необязательных параметра: -b - указывает на номер LBA, начиная с которого необходимо создать раздел. Если не указать данный параметр, то раздел будет создан автоматически с первого свободного LBA. -s - указывает на размер раздела в LBA. Размер одного блока LBA = 512 байт. Желательно указывать в количестве блоков LBA, но можно и в кило/мега/гига/… байтах (суффикс k/M/G). Если не указать данный параметр, то раздел будет создан до максимально возможного LBA в пределах пустой области. Также в качестве параметра можно указать метку раздела, например: -l swap1 - в этом случае будет создана метка /dev/gpt/swap1, по которой можно более удобно обращаться к разделу. Последним обязательным параметром идет путь к диску. В нашем случае: /dev/ada1.

Давайте создадим два раздела, а затем посмотрим, что у нас получилось. Первый раздел будем создавать без указания начального LBA, но с указанием размера 1 Гб (2097152 блоков). Второй раздел создадим без указания начального LBA и без указания размера - таким образом он будет создан на всем свободном пространстве.

Gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1 gpart show ada1

Размер можно указывать в байтах, а не блоках. Это значительно удобней. Единственный минус - система не всегда может корректно рассчитать количество блоков. Возможны случаи, когда на диске останется пустовать некоторое количество блоков при указании размера раздела в байтах.

Создание файловой системы (форматирование)

Разделы типа swap форматировать нет необходимости. А вот разделы типа ufs перед использованием должны быть отформатированы. Правильнее сказать: на них должна быть создана файловая система.

Для того, чтобы создать файловую систему на втором разделе, достаточно выполнить следующую команду:

Newfs -U /dev/ada1p2

В данном случае использовался параметр -U - он говорит о том, что в данной файловой системе должен использоваться механизм Soft Updates. Вы можете не использовать этот параметр, чтобы не включать данный механизм.

Монтирование

Следующим шагом будет монтирование разделов. Для начала, чтобы не забыть, добавим наши новые разделы в /etc/fstab. Мой файл после редактирования выглядит вот так:

Для того, чтобы перемонтировать все разделы согласно файла /etc/fstab, просто выполним команду:

Mount -a

Как видно из вывода, раздел /dev/ada1p2 смонтирован. Теперь посмотрим, что произошло с разделом SWAP. Выполним команду:

Как видно, новый раздел SWAP не смонтирован. Чтобы смонтировался SWAP, необходимо его включить специальной командой:

Swapon /dev/ada1p1

Точно так же при помощи команды swapoff нужно отключать раздел SWAP перед тем, как произвести над ним какие-то действия.

На этом все действия по добавлению нового жесткого диска в систему завершены.

Краткая инструкция

Дано : жесткий диск /dev/ada1

Цель : удалить существующую разметку, создать новую разметку GPT, создать два раздела: подкачка и данные и подключить их к рабочей системе.

После каждого действия выполняйте gpart show , чтобы наблюдать за результатом. Последовательность действий:

Удалить существующую разметку: gpart destroy -F ada1
Создать новую разметку: gpart create -s gpt /dev/ada1
Создать два раздела: подкачка и данные: gpart add -t freebsd-swap -s 2097152 /dev/ada1 gpart add -t freebsd-ufs /dev/ada1
Создать файловую систему UFSv2 на втором разделе: newfs -U /dev/ada1p2
Добавить в файл /etc/fstab строки для автомонтирования при загрузке: /dev/ada1p1 none swap sw 0 0 /dev/ada1p2 /mnt ufs rw 2 2
Смонтировать новый раздел (команда монтирует все разделы из файла /etc/fstab): mount -a
Включить в работу новый раздел swap командой: swapon /dev/ada1p1

На этом настройка завершена.

Созданием разделов и файловых систем на них дело подготовки дискового пространства к использованию не заканчивается. Все созданные файловые системы нужно еще сделать доступными для FreeBSD. Для чего они должны быть смонтированы - то есть включены в единую иерархию каталогов и файлов, для обозначения которой также используется название файловой системы. Однако если раньше речь шла о физической организации данных, то теперь пора ознакомиться с ее логикой.

Логика файловой системы

Логически файловая система FreeBSD (как и любой Unix-системы) организована по древовидному принципу: в основании ее лежит корень (корневой каталог, обозначаемый символом / и именуемый также root-каталогом; последнее не должно путать с каталогом /root , который выполняет роль домашнего для суперпользователя).

От корневого каталога, который можно уподобить скорее стволу дерева, отходят ветви - вложенные в него подкаталоги, и побеги - обычные файлы. Последних, правда, немного: в версиях FreeBSD это некий энтропийный файл (/entropy) и файл с описанием авторских прав на систему /COPYRIGHT .

А вот подкаталогов в корневом каталоге довольно много, и некоторые из них устроены внутри весьма сложно, содержа в себе изрядное количество вложенных подкаталогов более глубоких уровней.

В принципе иерархия каталогов во всех Unix-системах похожа, поскольку регламентируется, во-первых, многолетней традицией, во-вторых - всякого рода стандартизирующими документами, в частности, FHS (Filesystem Hierarchy Standard), который ныне доступен в русском переводе (за который спасибо Виктору Костромину).

Стандарт FHS был разработан первоначально для упорядочивания структуры каталогов в многочисленных дистрибутивах Linux. И лишь позднее он был приспособлен для других Unix-подобных систем (в том числе и BSD-клана). Однако именно иерархия каталогов FreeBSD может послужить примером для образцового следования духу FHS. А буквально штучные отступления в ней от его буквы всегда функционально обусловлены.

Стандарт FHS покоится на двух основополагающих принципах - четком отделении в файловой иерархии каталогов разделяемых и неразделяемых, с одной стороны, и неизменяемых и изменяемых - с другой.

Противопоставление разделяемых и неразделяемых каталогов обусловлено изначально сетевой природой Unix вообще и FreeBSD в частности. То есть данные, относящиеся к локальной машине (например, файлы конфигурирования ее устройств) должны лежать в каталогах, отдельных от тех, содержимое которых доступны с других машин в сети, локальной или глобальной (примером чему являются не только пользовательские данные, но и программы).

Суть противопоставления неизменяемых и изменяемых каталогов легко пояснить на примере. Так, те же пользовательские программы по природе своей должны быть неизменяемыми (вернее, доступными для модификации только администратору системы, но не самому пользователю, применяющему их в своей работе). В то же время эти программы при своей работе генерируют не только файлы данных, скажем, тексты или изображения (изменяемая их природа ясна без комментариев), но всякого рода служебную информацию, типа log-файлов, временных файлов и тому подобного). Каковая и должна группироваться в каталогах, отделенных от собственно исполнимых файлов программ, необходимых для их запуска библиотек, конфигурационных файлов и т.д.

Четкое следовании концепции отчленения разделяемых и неразделяемых, неизменяемых и неизменяемых каталогов друг от друга позволяет, в рамках единой древовидной файловой иерархии, обособить отдельные ее ветви физически - то есть в виде самостоятельных файловых систем, размещенных на изолированных устройствах (дисках, дисковых слайсах, разделах; в общем случае - и на удаленных, связанных по сети, носителях, но об этом не будет сейчас разговора). Резонов к тому много - и повышение быстродействия, и увеличение надежности, и просто соображения удобства, - но и о них сейчас речь не пойдет. Потому что сейчас для нас важно только то, что эти ветви файлового древа должны быть инкорпорированы в общую файловую систему.

В Unix-системах всякий файл (в том числе и каталог) опознается системой не по ее имени, а по уникальному идентификатору его записи в таблице inodes . Существуют средства для того, чтобы эти файловые идентификаторы просмотреть. Одно из них - команда ls с опцией -i , которая выведет идентификаторы каждого именованного файла. Данная для корневого каталога -

$ ls -i /

она покажет нам несколько неожиданную картину (для упрощения из вывода исключены сведения об обычных файлах и символических ссылках в корне, а оставшиеся каталоги отсортированы по их идентификаторам):

2 ../ 2 ./ 2 dev/ 2 home/ 2 tmp/ 2 usr/ 2 var/ 3 cdrom/ 4 mnt/ 5 root/ 8257 dist/ 8258 bin/ 8294 proc/ 8295 sbin/ 16512 stand/ 24768 etc/ 24776 boot/

Из этого примера (относящегося к файловой системе машины, на которой эти строки пишутся) видно, что аж 7 каталогов имеют одинаковые цифровые идентификаторы, равные 2. Спрашивается, какая же здесь уникальность?

С первыми двумя элементами списка разобраться легко: ./ представляет собой обозначение текущего каталога (в данном случае корневого), а../ - каталога, родительского по отношению к текущему; а поскольку выше корня в файловой иерархии по определению ничего нет, то последний обозначает самого себя. Так что неудивительно, что./ и../ имеют один и тот же идентификатор - это разные обозначения (жесткие ссылки, или, иначе говоря, дублирующие имена) для одного и того же, корневого, каталога.

А вот то же, как кажется на первый взгляд, значение идентификатора для каталогов /dev , /home , /tmp , /usr , /var требует объяснения. Однако оно - простое: все это каталоги, в которые смонтированы самостоятельные файловые системы, либо расположенные на отдельных устройствах - дисковых партициях, как каталоги /home , /usr , /var , либо виртуальные файловые системы, не надстраивающие какое-либо реальное дисковой устройство (каталог /dev с файловой системой устройств и, в данном случае, каталог /tmp , в который смонтирована файловая система в оперативной памяти, разговор о которых еще предстоит). А поскольку таблица inodes - своя для каждой файловой системы, нет ничего удивительного в том, что корень каждой из них идентифицируется числом 2 - нумерация inodes в них идет в собственной системе отсчета.

Так вот, монтирование - это и есть включение файловой с системы в какой-либо из существующих в корневой системе каталог (не обязательно непосредственно в корне, он может быть любой степени вложенности, что проиллюстрируется чуть ниже). Без этого каталоги и файлы такой монтируемой системы просто недоступны. Это важно понимать, когда сталкиваешься выражениями вроде "создать файловую систему /usr ". Из сказанного выше очевидно, что создается-то (командой newfs) просто некая абстрактная файловая система, а свое "имя" она обретает только в момент монтирования в указанный каталог.

Интересно, что и идентификатор каталога для монтирования (он еще именуется точкой монтирования, mount point) обретается только в момент монтирования. Чтобы убедиться в этом, проведем простой эксперимент. В каталоге /mnt , предназначенном специально для монтирования временно подключаемых файловых систем) можно увидеть три подкаталога - /mnt/disk , mnt/iso , /mnt/usb (это в моей системе, я их создал для собственного удобства; изначально каталог /mnt во FreeBSD пуст). При старте системы в них ничего не монтируется, и обычное их состояние - быть пустыми. Если просмотреть их идентификаторы, то можно видеть нечто вроде такого:

$ ls -i /mnt 18 disk/ 24 iso/ 19 usb/

Теперь возьмем и смонтируем в /mnt/usb флэш-накопитель с USB-интерфейсом (именно для этого я его и предназначал) и повторим просмотр. И видим:

18 disk/ 24 iso/ 2 usb/

То есть идентификаторы каталогов, оставшихся пустыми (/mnt/disk и /mnt/iso) не изменились, а идентификатор каталога /mnt/usb волшебным образом изменился на 2. Ибо в момент монтирования он стал корневым для своей собственной файловой системы и точкой отсчета для исчисления inodes всех записанных на ней файлов.

Немного отвлечемся и вспомним о жестких ссылках, посредством которых одному и тому же inode и относящимся к нему блокам данных могут быть присвоены разные имена. Теперь понятно, почему все такие файлы-дублеры должны лежать в одной файловой системе: ведь в разных файловых системах - своя, не совпадающая, нумерация inodes , и идентифицировать их по номерам невозможно (иначе как бы система отличила каталоги /usr и /var из нашего примера - ведь имена файлов ей глубоко до лампочки). Для символических же ссылок, имеющих собственные inode (собственно, и почти ничего, кроме них) со своими идентификаторами, нумеруемыми в системе отсчета файловой системы, в которой они находятся, такого ограничения нет. И могут символические ссылки лежать где угодно (в том числе и на удаленной машине - не только на ином разделе).

Вернемся, однако, к примеру нашего корневого каталога. Из всего рассмотренного видно, что целый ряд его ветвей лежит на отдельных партициях и образует собственные файловые системы (собственно, именно для этого мы и создавали и те, и другие). И, следовательно, все они нуждаются в монтировании.

Практика монтирования

Целям монтирования служит команда mount , выполняемая либо в ходе загрузки системы автоматически, либо - вручную, из командной строки. Собственно, в полном смысле автоматически в любом случае монтируется только корневая файловая система. Не обязательно лежащая на диске - при старте с rescue CD или иного страховочного носителя она может располагаться на виртуальном диске в оперативной памяти.

Однако процесс монтирования корневой файловой системы столь же неизбежен, как победа социализма в мировом масштабе: также, как социализм, не победив в мировом масштабе, просто утрачивает способность к существованию (что мы не так давно и наблюдали), так и ОС без корневой системы существовать не может. В Linux это вызывает kernel panic mode - примерно то состояние, в которое впали наши вожди лет 20 назад. Правда, они оказались крепче Linux"а и оклемались довольно быстро - так что до сих пор нас reboot"ят (или reboot? - а мы крепчаем:)). Впрочем, к делу монтирования, которое я попытаюсь вам сейчас представить, это не относится.

Так вот, для монтирования всех файловых систем, кроме корневой, необходимо предпринять некоторые действия. Сначала мы рассмотрим, как выполнить их руками, а потом - как увековечить в соответствующих конфигурационных файлах.

Итак, команда mount . Собственно, это - целое семейство программ, каждая из которой призвана монтировать файловые системы определенных типов - не только UFS, но и любой из числа поддерживаемых FreeBSD. Список таковых весьма обширен - получить о нем представление можно, просмотрев на сей предмет каталог /sbin:

$ ls -1 /sbin/mount*

что даст нам в ответ

/sbin/mount_cd9660* /sbin/mount_devfs* /sbin/mount_ext2fs* /sbin/mount_fdescfs* /sbin/mount_linprocfs* /sbin/mount_mfs* /sbin/mount_msdosfs* /sbin/mount_nfs* /sbin/mount_nfs4* /sbin/mount_ntfs* /sbin/mount_nullfs* /sbin/mount_procfs* /sbin/mount_std* /sbin/mount_udf* /sbin/mount_umapfs* /sbin/mount_unionfs*

Каждая команда из этого списка отвечает за монтирование своего типа файловой системы, к некоторым из которых мы вернемся дальнейшем. А пока заметим только собственно /sbin/mount , предназначенную для работы с UFS и UFS2.

Вызванная из командной строки, она требует двух аргументов - имени монтируемого устройства и точки монтирования (то есть каталога, в который должна монтироваться лежащая на нем файловая система). Имя устройства должно обозначать уже размеченную на существующем BSD-слайсе патрицию с созданной на ней файловой системой UFS2 (UFS), например,

$ mount /dev/ads0d /usr

смонтирует файловую систему на указанном разделе в каталог /usr корня файлового древа. Если файловая система на устройстве не создана или имеет тип, отличный от UFS/UFS2, последует сообщение об ошибке - указание на incorrect super block: в отличие от одноименной утилиты Linux, сама по себе команда mount во FreeBSD распознавать тип файловой системы не умеет.

К точке монтирования предъявляются следующие требования: а) каталог с таким именем должен существовать к моменту монтирования, и б) быть по возможности пустым. Первое - обязательно, второе же - не совсем. Монтирование в каталог с какими-либо файлами пройдет беспрепятственно (помнится, в Linux не так давно это вызывало крах системы), но все его содержимое станет недоступным вплоть до размонтирования. И если файлы, в нем содержащиеся, имеют играют существенную роль для какой-либо подсистемы, это может вызвать всякие нехорошие последствия. Например, если содержимое каталога /tmp будет блокировано монтированием туда какой-либо файловой системы во время работы оконной системы X, результатом будет скорее всего крах X-сервера. Благо, при необходимости можно осуществить объединенное монтирование (см. ниже).

В указанной форме монтирование выполнится с некоторыми умолчальными характеристиками: файловая система будет доступна для чтения/записи в режиме т.н. noasync (том самом, при котором операции с метаданными осуществляются синхронно, а операции с данными - асинхронно). Изменить это положение можно с помощью значений опции -o . Их довольно много, однако практически главными на данном этапе для нас будут:

async - обеспечит полностью асинхронный режим (не смотря на грозные предупреждения в предыдущих заметках, я потом расскажу о ситуации, когда это может быть оправдано);
sync - напротив, включение полностью синхронного режима (правда, не очень представляю, зачем это практически нужно);
noatime - очень полезная опция, которая предотвращает обновление атрибута времени последнего доступа к файлам, чем немало способствует производительности;
rdonly - монтирует файловую систему в режиме только для чтения (иногда это бывает необходимо);
union - та самая опция, которая позволяет выполнить объединенное монтирование, при котором прежнее содержимое каталога mount point остается видимым; правда - с некоторыми ограничениями - см. man (8) mount .

Есть еще несколько значений опции -o , запрещающих размещение на смонтированной файловой системе файлов определенных разновидностей, например, исполняемых (-o noexec), файлов устройств (-o nodev) или файлов с т.н. битом суидности. Однако они имеют практическое значение в основном для администраторов серверов и служат целям безопасности. На настольной же машине обычной формой монтирования будет нечто вроде этой:

$ mount -o noatime /dev/ads0d /usr; $ mount -o noatime /dev/ads0e /var; $ mount -o noatime /dev/ads0f /home

Все сказанное относилось только к монтированию файловых систем FreeBSD. Однако на практике часто возникает необходимость инкорпорации в ее древо каталогов файловых систем других типов. Особенно часто это требуется для ISO9660 (обычная файловая система для всех компакт-дисков, кроме Mac"овских) и FAT"ов разного рода. В этом случае соответствующая случаю команда монтирования должна быть вызвана явно, например,

$ mount_cd9660 /dev/acd0 /cdrom

для монтирования компакта, или

$ mount_msdosfs /dev/ad## /mnt

для FAT"а любого рода (включая FAT32). Впрочем, сделать это можно и косвенно, указанием команде mount опции -t тип_файловой_системы. Так, команда

$ mount -t ext2fs /dev/ad## /mnt/linux

смонтирует файловую систему Linux (если соответствующая возможность включена в ядро). При этом стандартный mount для BSD-разделов просто подменяется командой /mount_ext2fs , призванной монтировать разделы ext2fs (и ext3fs тоже - но, естественно, без всяких функций журналирования). То есть форма

$ mount -t fstype ... ...

будет полным эквивалентом команды

$ mount_fstype ... ...

Все операции по монтированию файловых систем (в том числе и на сменных носителях) во FreeBSD требуют прав суперпользователя. В числе значений опции -o здесь, в отличие от Linux-варианта команды mount , нет параметра -o user , разрешающего монтирование обычным пользователям. Правда, есть несколько способов обойти это, о чем говорится в специальной заметке .

Настройка автоматического монтирования

Однако на практике к ручному монтированию прибегают только для редко используемых файловых систем. Все принципиально важные для функционирования FreeBSD файловые системы монтируются автоматически при старте системы, а часто используемые - в полуавтоматическом, так сказать, режиме.

Для автоматического монтирования программа mount запускается в процессе начальной загрузки из инициализационных сценариев. Она отыскивает свой конфигурационный файл - /etc/fstab , и монтирует все, что в нем обнаружит, за некоторыми (оговоренными ниже исключениями).

Сам по себе файл /etc/fstab генерируется автоматически при установке FreeBSD, включая все необходимые для обеспечения жизнедеятельности файловые системы. Однако в дальнейшем он может правиться вручную с целью внесения новых устройств для монтирования или дополнительных опций для уже включенных устройств.

Файл /etc/fstab - это простенькая база данных в текстовом формате (разделение полей - пробелами или табуляцией), включающая следующие поля:

Device - имя файла устройства, на котором расположена файловая система, аналогично первому аргументу команды mount при ручном ее использовании;
Mountpoint - точка монтирования (соответствует второму аргументу команды mount);
FStype - тип файловой системы, указываемый также, как значение опции -t ;
Options - дополнительные опции монтирования, аналогично значениям опции -o ;
Dump - условия выполнения резервного копирования файловой системы утилитой утилитой dump ;
Pass# - условия проверки файловой системы утилитой fsck .

В свежеустановленной FreeBSD /etc/fstab в обязательном порядке будет включать следующие записи (пример для 1-го слайса Master-диска на 1-м IDE-канале):

# Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1b none swap sw 0 0

Если последовать советам резонных людей (и умолчаниям sysinstall) и выделить из состава корня некоторые ветки файловой системы, к перечисленным добавятся (при автоматической разметке слайса через sysinstall) еще и записи вроде

/dev/ad0s1d /var ufs rw 0 0 /dev/ad0s1e /usr ufs rw 0 0 /dev/ad0s1f /tmp ufs rw 0 0

/dev/ad0s1g /home ufs rw 0 0

отвечающая за файловую систему с домашними каталогами пользователей.

Очевидно, что в поле Options можно добавить любые доступные (и разумные) значения опции -o (через запятую, без пробелов), например, noatime для всех файловых систем, а для /tmp - еще и async , ведь для содержимого этого каталога не предполагается сохранение после перезагрузки.

Сказанное выше относилось к файловым системам, монтируемым при старте автоматически. Однако никто не мешает сделать в /etc/fstab записи для систем, подключаемым время от времени - в этом случае их можно будет монтировать по упрощенной схеме (именно это я и имел ввиду выше под полуавтоматическим режимом). Так, для CD-накопителя можно добавить строку (на самом деле она автоматически появляется при генерации файла /etc/fstab , если в sysinstall в качестве источника инсталляции выбирался CD)

/dev/acd0 /cdrom cd9660 ro,noauto 0 0

в которой опции, как нетрудно догадаться, предписывают отказ от монтирования при старте (noauto) и режим "только для чтения" (ro). После чего для монтирования CD достаточно будет указать только mount point -

$ mount /cdrom

или. напротив, имя файла устройства

$ mount /dev/acd0

Аналогичные записи можно сделать для всех сменных накопителей (Zip, USB-драйвов, даже флоппи-дисков) и для не-BSD разделов (FAT или Ext2fs). К слову сказать - монтировать файловые системы по упрощенной схеме можно сразу после внесения изменений в /etc/fstab , не дожидаясь перезагрузки машины.

Размонтирование

Все задействованные файловые системы перед выключением питания или перезагрузкой машины в обязательном порядке должны быть размонтированы. При корректном завершении работы это осуществляется автоматически, в результате чего каждая из доступных для записи файловых систем получает бит чистого размонтирования, записываемый в ее своем суперблоке. Наличие этого бита предотвращает при следующем запуске системы проверки файловых систем на непротиворечивость утилитой fsck .

Однако в ряде случаев (например, при подключении или отключении механизма Soft Updates или для выполнения проверки на целостность) возникает необходимость ручного размонтирования (и повторного монтирования) файловых систем, для чего служит команда umount . Она требует единственного аргумента - указания точки монтирования файловой системы, "изымаемой" из древа каталогов, например:

$ umount /tmp

или, как и в случае с полуавтоматическим монтированием, имени файла "выключаемого" устройства:

$ umount /dev/ad#s#?

Одной строкой можно размонтировать несколько файловых систем:

$ umount /usr /var /home

А можно - все смонтированные файловые системы или все файловые системы, перечисленные в файле /etc/fstab (кроме корневой), для чего потребуются опции

$ umount -A

$ umount -a

соответственно. Есть и возможность размонтирования файловых систем определенных типов путем указания значений опции -t . Так, команда

$ umount -t ufs

размонтирует только BSD-разделы, не затронув CD и всего остального, что задействовано в системе.

Файловые системы в момент размонтирования не должны использоваться, то есть не должно быть обращений к находящимся на них файлам. Так, нахождение в каком-либо каталоге файловой системы - достаточное основание для отказа в ее размонтировании (с выдачей сообщения типа device busy), почему ни одной из перечисленных выше команд и не удастся размонтировать корневую файловую систему. Поводом для отказа в размонтировании будет и считывание файла данных какой-либо программой - как и при удалении файла, открытый любым процессом дескриптор файла сделать это не позволит.

Впрочем, можно размонтировать и используемую файловую систему - для этого команду umount потребуется дать с опцией -f (от force - то есть насильно). Правда, это может привести к ошибкам, так что без острой необходимости лучше к ней не прибегать. И на корневую файловую систему опция принудительного размонтирования воздействия не окажет.

Массовое монтирование

Для продолжения работы после выполнения низкоуровневых операций с файловыми системами их потребуется смонтировать обратно. Это можно сделать не только без перезагрузки, но и без нудного индивидуального монтирования. Достаточно прибегнуть к опции -a:

$ mount -a

посредством которой будут смонтированы все файловые системы, для которых имеются записи в /etc/fstab . При этом будет предпринята попытка смонтировать и те из них, которые помечены флагом noauto . Чтобы избежать этого, можно дополнительно определить тип файловой системы. То есть команда

$ mount -a -t ufs

смонтирует только BSD-разделы, не покушаясь на CD или флэш-накопители. А можно, напротив, исключить из процесса глобального монтирования какие-то из перечисленных в /etc/fstab файловых систем, например, ненужные в данный момент FAT"ы:

$ mount -a -t nomsdosfs

Преамбула вместо заключения

К слову сказать, команда mount без опций и аргументов (а в такой форме, в отличие от всех рассмотренных выше случаев, ее может дать и обычный пользователь) выведет список смонтированных в данный момент файловых систем с указанием точки монтирования, условий оного и режима работы. Например, для машины, на которой пишутся эти строки, вывод ее будет выглядеть так:

/dev/ad0s1a on / (ufs, local, noatime, soft-updates) devfs on /dev (devfs, local) /dev/ccd0e on /var (ufs, local, noatime, soft-updates) /dev/ccd1e on /usr (ufs, local, noatime, soft-updates) /dev/ccd2e on /home (ufs, local, noatime, soft-updates) /dev/md0 on /tmp (ufs, local, noatime, async)

Первая строка вывода показывает, что партиция /dev/ad0s1a смонтирована у нас в корневом каталоге, несет на себе файловую систему UFS (конкретно в данном случае - UFS2, но в выводе команды mount они не различаются) с задействованным механизмом Soft Updates, является локальной (то есть расположена на диске этой машины - сетевые диски также монтируются командой mount) и не подвержена обновлению атрибута atime .

$ more /etc/fstab /dev/ad0s1b none swap sw 0 0 /dev/ar0s1b none swap sw 0 0 /dev/ad0s1a / ufs rw,noatime 1 1 /dev/ccd0e /var ufs rw,noatime 2 2 /dev/ccd1e /usr ufs rw,noatime 2 2 /dev/ccd2e /home ufs rw,noatime 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/da0s1 /mnt/usb ext2fs rw,noauto,noatime 0 0 /dev/md0 /tmp mfs rw,noatime,async,-s32m 2 0

то увидим, что одной из строк вывода

Devfs on /dev (devfs, local)

вообще нет соответствия среди его записей. Что это за устройства и файловые системы?