Технологии Solaris и Администрирование Solaris

Краткий конспект лекций по авторскому курсу «Технологии Solaris и Администрирование Solaris»

Версия 0.1. Пожалуйста, расскажите тренеру или составителю о найденных в конспекте ошибках или
опечатках. Авторы будут благодарны за отзыв о содержании и исполнении конспекта.

Предлагается преподавателям в качестве одного из учебных материалов к курсу «Технологии Solaris и

Администрирование Solaris». Данные материалы можно свободно использовать для добавления в курсы для
студентов. Условием использования этих материалов является согласие использующего на применение
немодифицированных материалов данного авторского курса только для преподавания в некоммерческих
учебных заведениях для студентов. Коммерческое использование данных материалов запрещено.

При использовании информации для подготовки лабораторных работ рекомендуется проверить версию
программного обеспечения, установленного в лаборатории – данные материалы разработаны на основе опыта
эксплуатации Solaris Express Developer Edition 9/07 и Solaris 10 11/06. Версии Solaris, более ранние, чем Solaris
10 11/06, могут не иметь части описанных особенностей.

Документ подготовил Филипп Торчинский, консультант по Solaris компании Sun Microsystems. В документе
использованы авторские материалы Филиппа Торчинского и Сергея Пикалева, а также презентации ряда
сотрудников Sun Microsystems на конференциях и документация Sun Microsystems.

Содержание
Программное обеспечение с открытым кодом. Обзор особенностей Solaris.................................3
Введение. Программное обеспечение с открытым кодом. ..........................................................3
Дистрибутивы, основанные на открытом коде Solaris..................................................................4
Отличия Solaris от других операционных систем.........................................................................5
Установка Solaris.....................................................................................................................................7
Совместим ли Solaris с вашим компьютром?.................................................................................7
Подготовка...........................................................................................................................................8
Установка шаг за шагом....................................................................................................................8
Первый запуск..................................................................................................................................11
Куда делись другие операционные системы?..............................................................................11
Доводка..............................................................................................................................................12
Дополнительные источники пакетов.............................................................................................13
Управление пользователями................................................................................................................14
Зачем распределять пользователей по группам?.........................................................................14
Концепция безопасности UNIX.....................................................................................................15
Объект...........................................................................................................................................15
Разделение всех пользователей по отношению к объекту....................................................15
Назначение прав доступа по-отдельности...............................................................................16
Каждый объект имеет владельца и группу..............................................................................16
Структура файлов /etc/passwd, /etc/shadow, /etc/group.................................................................16
Учетные записи пользователей.................................................................................................17
Пользовательские файлы конфигурации.................................................................................20
Группы пользователей................................................................................................................20
Программы управления учетными записями пользователей....................................................21
Solaris Management Console........................................................................................................22
useradd...........................................................................................................................................23
Управление дисками и файловыми системами. Общий обзор.......................................................25
Термин “файловая система”...........................................................................................................25
Две концепции файловой системы в UNIX..................................................................................26

1
 Файлы устройств в Solaris...............................................................................................................27
файлы устройств для разделов дисков в Solaris...........................................................................28
Жесткие диски.............................................................................................................................28
каталог /devices............................................................................................................................31
Структура файловых систем, соответствующих POSIX............................................................32
Основные понятия: суперблок, метаданные, точка монтирования.....................................32
монтирование и демонтирование файловых систем...................................................................34
монтирование дискет и прочих сменных носителей..................................................................35
Суперблок.....................................................................................................................................36
Таблица индексных дескрипторов............................................................................................36
Дерево каталогов.........................................................................................................................36
Поддерживаемые типы файловых систем...............................................................................36
дерево каталогов..........................................................................................................................39
файлы и каталоги.............................................................................................................................40
типы файлов.................................................................................................................................40
имена файлов и каталогов..........................................................................................................41
действия с файлами и каталогами............................................................................................43
Каталоги........................................................................................................................................44
ссылки................................................................................................................................................45
права доступа....................................................................................................................................47
индексные дескрипторы..................................................................................................................49
списки ACL........................................................................................................................................49
Расширенные права доступа (ACL) к файлам.........................................................................50
Расширенные права доступа (ACL) к каталогам....................................................................51
Монтирование файлов в качестве устройств (lofi)......................................................................52
Устройство и администрирование файловой системы UFS...........................................................53
разбиение диска на разделы...........................................................................................................53
разметка нового диска.....................................................................................................................54
количество индексных дескрипторов в файловой системе...................................................56
элементы файловой системы..........................................................................................................56
таблица индексных дескрипторов: детали...................................................................................57
обычные индексные дескрипторы............................................................................................59
теневые индексные дескрипторы..............................................................................................59
оптимизация размеров разделов....................................................................................................60
как узнать, сколько места осталось на диске?.........................................................................61
Минимальное свободное пространство...................................................................................62
фрагментация....................................................................................................................................63
изменение размеров раздела...........................................................................................................64
проверка файловых систем.............................................................................................................64
Концепция, устройство и администрирование ZFS.........................................................................65
Концепция ZFS.................................................................................................................................65
Пулы накопителей вместо разрозненных дисков...................................................................65
Сквозной контроль целостности...............................................................................................66
Транзакционность.......................................................................................................................68
Легкость администрирования....................................................................................................68
ZFS в работе......................................................................................................................................68
элементы файловой системы.....................................................................................................68
виртуальные устройства (vdev), метки виртуальных устройств и загрузочный блок..69
Виртуальные устройства..................................................................................................69
Метки виртуальных устройств........................................................................................70

2
 Содержание метки виртуального устройства................................................................71
указатели блоков и блоки косвенной адресации................................................................74
копирование при записи данных в ZFS (copy on write)..........................................................80
снимки и резервное копирование.............................................................................................80
RAID-Z..........................................................................................................................................81
Резервирование метаданных.....................................................................................................82
масштабируемость ZFS..............................................................................................................83
производительность ZFS............................................................................................................83
Практическое администрирование ZFS: команды..................................................................85
Квотирование и резервирование пространства......................................................................86
Дополнительные материалы для чтения о ZFS...........................................................................87
Управление процессами и проектами................................................................................................87

Программное обеспечение с открытым кодом. Обзор

особенностей Solaris.

Введение. Программное обеспечение с открытым кодом.

Программным обеспечением (ПО) с открытым кодом называется такое ПО, которое:

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

Также различают бесплатное ПО, которое называют также свободным (по принципу
распространения – свободно, без оплаты).

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

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

3
Например, пакет офисных программ StarOffice 81, функционально практически идентичный
другим широко распространенным офисным пакетам, использует для хранения данных
открытый стандарт, но допускает сохранение и импорт данных в закрытых форматах других
офисных пакетов.

Существуют десятки тысяч программных пакетов с открытым кодом; однако большое

влияние на распространение современных технологий оказывают, как правило, немногие из
них. Среди них выделяются операционные системы с открытым кодом. Подавляющее
большинство таких систем происходят от операционной системы UNIX, первая версия
которой была разработана в 1969 году. Примером такой системы является Solaris. История
этой системы началась в 1982 году, и ее код был открыт в июне 2005 года, поэтому системой с
открытым кодом могут считаться версии Solaris 10, начиная с версии 11/062.

Дистрибутивы, основанные на открытом коде Solaris

Solaris работает на платформах SPARC, x86 и x64 – с процессорами от Sun, AMD и Intel, на
компьютерах любого масштаба – лаптопах, десктопах, рабочих станциях, серверах и в
кластерах. Как и другие системы UNIX, Solaris в силу архитектурных особенностей
потенциально менее подвержен вирусам, чем широко распространенные системы других
архитектур. На практике подтвержденных случаев заражения Solaris 10 вирусами не
зарегистрировано вообще.

Код Solaris 10 сейчас доступен для всех на сайте opensolaris.org. После того, как код ОС
Solaris был открыт, и был анонсирован проект OpenSolaris, смысл которого – в
усовершенствовании базовой системы, появилось несколько дистрибутивов, основанных на
этом коде:
● Solaris Express Community Edition – самый свежий двоичный (без исходных кодов в
поставке) дистрибутив для тех, кто хочет испробовать самые новые технологии, еще
не включенные в другие дистрибутивы, и еще не опубликованные в сборнике кодов на
opensolaris.org. Обновляется раз в две недели. Этот дистрибутив еще называют Solaris
Nevada, build XX, указывая соответствующий номер выпуска. Работает на платформах
SPARC, x86/x64. На его основе создается другой дистрибутив, Solaris Express Developer
Edition;
● Solaris Express Developer Edition – тестируемый Sun Microsystems дистрибутив,
распространяется для x86, однако может быть собран из компонент для SPARC.
Выпускается раз в три месяца;
● BeleniX – дистрибутив, созданный с использованием исходного кода, открытого в
рамках проекта OpenSolaris. Сейчас распространяется в виде загружаемой с CD
системы (LiveCD), однако разработчики рассчитывают сделать из него полноценный
дистрибутив с установкой на диск;
● marTux – первый не связанный с выпусками Solaris Express и сообществом
разработчиков Solaris Express дистрибутив для SPARC;

1 StarOffice 8 – это ПО с закрытым кодом, использующее открытые стандарты. На данный момент продается
за деньги, однако для образовательных и исследовательских организаций бесплатен для всех
поддерживаемых ОС – Solaris, Linux и Windows. Кроме того, StarOffice 8 входит в дистрибутив Solaris
Express Developer Edition, и поэтому оказывается бесплатным для всех пользователей этой ОС. Пользователи
Windows могут его скачать и использовать бесплатно в составе Google Pack от Google.
2 В ОС Solaris версии нумеруются в виде MM/YY, т.е. месяц/год, 11/06 означает выпуск, вышедший в ноябре
2006 года – прим. авт.

4
 ● Nexenta – распространяемая по лицензии GNU система, разработанная на основе
открытого кода ядра Solaris. Nexenta объединяет ядро Solaris и разнообразные
открытые приложения;
● SchilliX, основанный на коде Solaris дистрибутив на Live CD для x86/x64/EM64T.

Помимо упомянутых дистрибутивов, развиваемых широким сообществом разработчиков, как

связанных с компанией Sun Microsystems, так и совершенно независимых от нее, надо
отметить собственно Solaris (текущая новейшая версия на осень 2007 года – Solaris 10 update
4, также именуемая Solaris 10 08/07). Компания Sun внимательно изучает опыт разработчиков
и пользователей Solaris Express и обеспечивает перенос (портирование) в очередные
выпуски Solaris новых технологий и функциональностей, опробованных в Solaris Express.

Отличия Solaris от других операционных систем

Чем Solaris отличается от других систем, происходящих от UNIX? Ее удобнее

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

Коротко, вот основные преимущества Solaris перед другими операционными системами с

открытым кодом:

● уникальный механизм виртуализации

● сверхнадежная транзакционная файловая система, легкая в управлении
● гибкое делегирование прав с помощью ролей (RBAC – role-based access control)
● легкое управление запуском и настройкой служб
● динамическая трассировка программ
● устойчивость к нагрузке - в частности, благодаря современному планировщику задач
● улучшенное быстродействие стека TCP/IP
● обратная совместимость по исполняемым кодам на 10 версий назад
● централизованная поддержка от производителя

А теперь разберем самые интересные преимущества подробнее.

Встроенный механизм виртуализации – возможность запустить в рамках одной

операционной системы до 8192 виртуальных систем (так называемых контейнеров или
“зон”). Каждая зона работает независимо от других, со своим собственным участком
дискового пространства, своим уникальным IP-адресом, и даже своим собственным
пользователем root. Зону можно ограничить в использовании оперативной памяти и
процессорной мощности, что выгодно отличает зоны от похожих по назначению
“клеток” (jails) во FreeBSD. Более того, в зонах специального типа можно запускать двоичные
приложения для Linux, в том числе Oracle для Linux – без какой-либо модификации. Это
достигнуто за счет измененного механизма обработки системных вызовов в ядре,
позволяющего исполнять их таким же образом, каким они выполняются в другой системе.

Все зоны разделяют между собой одно ядро, работающее в главной, “глобальной” зоне, и это
значительно снижает накладные расходы зон на планирование задач, делая это решение
самым эффективным среди всех вариантов виртуализации серверов (а еще есть как минимум
Xen, VMware и Qemu – с которыми Solaris 10 тоже полностью совместим).

5
Совершенно новая 128-разрядная транзакционная файловая система ZFS – по архитектуре и
применяемым техническим решениям. В ней нет традиционных томов, равно и проблем с
недостатком свободного места или нехваткой индексных дескрипторов. Благодаря
транзакционному механизму даже при неожиданном отключении питания занудной проверки
диска после старта не последует: все назаконченные транзакции тихо исчезнут. ZFS легко и
логично администрируется, имеет новый, совместимый с NFSv4 набор прав доступа (схожий
с применяемым в NTFS), в частности, наследование прав доступа от родительского каталога.
Другие впечатляющие новинки – сквозное контрольное суммирование не только данных, но и
метаданных, мгновенное создание “снимков” (образов всей файловой системы), незаменимое
для резервного копирования “на ходу” , программное зеркалирование, RAID с переменным
размером полос, возможность двойной избыточности программных RAID-массивов RAID-Z
(этого обычно нет и в аппаратной реализации избыточности), и долгожданный рост
максимального размера файлов и файлового хранилища: теперь максимальный размер файла
равен 264 байт.

В других системах UNIX для того, чтобы доверенный пользователь мог выполнить какую-то
административную задачу (скажем, добавить пользователя), ему либо сообщают пароль root,
либо он использует sudo. И то, и другое решение неидеально. Строгие правила безопасности
и печальный опыт поколений требуют, чтобы пароль привилегированного пользователя был
известен минимальному количеству людей (в идеале - одному человеку и еще записан на
бумаге у него в сейфе). А sudo всего лишь позволяет исполнять определенные программы, в
то время как по сути надо делегировать выполнение определенных обязанностей. Тонкая
настройка прав доступа в Solaris позволяет делегировать обычным пользователям строго
необходимые им права, напрмер “добавлять принтер”, “выбирать сеть wi-fi для
подключения”. Ничего лишнего: только то, что требуется. Добавляющий только принтеры не
сможет добавить пользователя, а выбирающий сеть для подключения не сможет установить
новый ключ для шифрования в протоколе WEP.

Архитектура Solaris препятствует созданию вирусов для этой системы, а надежная

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

Для быстрого, безопасного и автоматического обновления компонентов Solaris компания Sun

Microsystems разработала Sun Online Connection – механизм обновлений для
зарегистрированных пользователей. Для его использования необходимо зарегистрироваться
на сайте, и разумеется его можно отключить, если загрузка обновлений стала невозможна
(например, снизилась пропускная способность канала связи или приходится экономить
деньги на трафике).

Уникальное средство управления службами (SMF – Service Management Facility) позволяет

отслеживать зависимости служб друг от друга, отслеживать проблемы при их запуске и
управлять запуском и остановом. Это средство унифицирует работу всех служб – как
запускаемых с помощью init.d, так и независимо работающих серверов типа Apache. Это
новшество значительно облегчает работу администратора. Такого средства пока нет ни в
одной другой системе UNIX.

6
Для более опытных системных администраторов и разработчиков есть еще динамический
трассировщик DTrace, позволяющий отследить цепочку системных вызовов любой
программы или ядра, а также померять время, которое процессор потратил на выполнение
любой группы вызовов. Функциональность DTrace встроена в ядро и не требует
перекомпиляции программ для отслеживания их кода.

Установка Solaris

Совместим ли Solaris с вашим компьютром?

Перед тем, как устанавливать Solaris на свой компьютер, было бы неплохо узнать, а возможно
ли это в принципе, и будет ли обеспечена работа необходимых вам устройств под Solaris.
Итак, способ первый – Sun Device Detection Tool. Найти его можно здесь:
http://www.sun.com/bigadmin/hcl/hcts/device_detect.html
Данный инструмент представляет собой jnlp-приложение, которое читает информацию о всех
устройствах, которыми снабжен ваш компьютер, и выдает таблицу с информацией, имеются
ли драйвера для этих устройств в Solaris. Помимо драйверов, содержащихся в базе
OpenSolaris, инструмент знает о некотором количестве сторонних драйверов, и дает на них
ссылку.
Для запуска Sun Device Detection Tool необходимо наличие на вашей машине JRE версии не
ниже 1.4 и утилиты javaws. Достоинства данного способа состоят в том, что не требуется
перезагружать машину для ее запуска, а результаты представлены в виде красивой таблички.
Недостатки – необходимость подключения к сети интернет и наличия установленной JRE.
Способ второй – Installation Check Tool. Он расположен здесь:
http://www.sun.com/bigadmin/hcl/hcts/install_check.html
Это тот же самый Device Detection Tool, только без Java и оформленный в виде Live CD. То
есть, загрузочный диск, с котрого запускается Detection Tool и рисует таблицу устройств и
драйверов к ним в текстовом виде.
Достоинства этого способа – независимоть от наличия сети интернет под руками. Недостатки
же в том, что требуется перезагрузка (что, впрочем, не страшно, если вы уже решились
инсталлировать новую систему), и в том, что в текстовой табличке некоторые длинные
строки не видны целиком.
Способ третий – Hardware Compatibility List. Две ссылки указывают на HCL для Solaris 10 и
для OpenSolaris соответственно:
http://www.sun.com/bigadmin/hcl/data/sol/
http://www.sun.com/bigadmin/hcl/data/sx/
В этих списках можно поискать свое оборудование и узнать, есть для него драйвера в Solaris.
Недостатком этого способа является время, которое можно потратить на поиск. Безусловным
же достоинством – наибольшая точность информации, потому что база для указанных выше
инструментов обновляется достаточно часто, но все же не при каждом добавлении нового
устройства в список совместимости, и HCL является первичным источником этого
обновления.
Однако, даже если вы не нашли поддержки каких-то из устройств вашего компьютера в
opensolaris – это еще не повод расстраиваться. HCL содержит в себе далеко не все ссылки на

7
драйвера сторонних производителей, и особенно это касается драйверов с закрытым кодом.
Так что поиски можно продолжить.
Во-первых, имеет смысл посетить сайт производителя самого устройства. Последнее время
многие производители железа сопровождают свои устройства драйверами и для ОС Solaris.
Во-вторых, имеет смысл посетит страницу http://www.sun.com/bigadmin/hcl/indexRes.html, где
можно найти большое количество ссылок на сторонних производителей драйверов для
Solaris.
Ну и в-третьих, творческое использование поисковых систем иногда творит чудеса.

Подготовка
Итак, вы решились поставить Solaris на ваш компьютер.
Первое, что нужно сделать – отвободить место на диске. Минимальная инсталляция (без X-
Window) занимает чуть больше двух гигабайт. Полная – около шести. С учетом swap 8-10
гигабайт будет вполне достаточно.
Некоторые тонкости, о которых хочется предупредить сразу. Во-первых, не стоит помечать
раздел как Solaris с помощью gparted или fdisk из Linux. Они «думают», что ставят
правильный идентификатор, но на самом деле это не так. Самое простое – это сделать на
диске просто пустое неразмеченное место. Инсталлятор Solaris найдет его и обработает
корректно. Впрочем, если у Вас уже стоял Solaris 10 (или Вы уже пометили раздел как Solaris
при помощи fdisk из инсталлятора Solaris), то в этом случае идентификатор раздела
правильный, и убирать его не надо. Инсталлятор найдет этот раздел и предложит поставиться
в него.
Во-вторых, Solaris не может поставиться в расширенные разделы, ему нужно именно пустое
место на диске.
В-третьих, если у вас уже установлен Linux, и вы планируете его сохранить, то обязательно
скопируйте куда-нибудь содержимое файла /boot/grub/menu.lst, оно потом
пригодится.
А в-четвертых, если у вас есть Linux swap в первичном разделе, удалите его. Потому что по
каким-то причинам идентификатор раздела Solaris совпадает с идентификатором Linux swap.
Восстановить работоспособность Linux можно будет позже. Но не забудьте при выделении
маста для Solaris оставить место и для восстановления Linux swap.

Установка шаг за шагом

Итак, грузимся с инсталляционного диска. Первым делом загружается GRUB. В его меню мы
можем выбрать, что мы хотим установить – Community Edition или Developer Edition. Второй
отличается от первого упрощенной процедурой установки и набором средств разработки –
Sun Studio и NetBeans. Поскольку установщик средств разработки запускается поверх
установщика операционной системы, Developer Edition довольно требовательный по памяти –
ему надо 768Мб. Однако средства разработки лежат на том же диске, и поставить их позже не
составит труда даже на компьютер с меньшим количеством оперативной памяти. Здесь
рассказано о более сложном способе установке — установке Community Edition. Поэтому
смело выбираем второй пункт.
Далее появится меню, где можно выбрать, как мы будем устанавливать. Оно содержит три
варианта установки Solaris Interactive – полностью графический, текстовой инсталлятор в

8
графическом окне и полностью текстовый. Функционально все они эквивалентны. Также в
меню наличествует пункт Custom JumpStart. Это сильно кастомизируемая установка, и в
данной случае мы ее рассматривать не будем.
Для запуска графического инсталлятора вам потребуется наличие 400Mb оперативной
памяти. Если у вас меньше – используйте текстовые режимы. Впрочем, инсталлятор сам
определит, что он не может запустить графику и перейдет в текстовый режим. Если вы
решили использовать графический инсталлятор, то в данный момент не стоит отвлекаться от
монитора: перейдя в графический режим, система спросит, все ли хорошо видно, и если в
течение определенного времени ей не сообщить, что все в порядке, она автоматически
перейдет в текстовый режим.
Далее страница за страницей и этап за этапом система будет задавать вопросы.
В текстовом режиме переход от страницы к странице (и от этапа к этапу) по причинам чисто
исторического характера осуществляется функциональными клавишами. Например, вперед –
клавишей F2, назад – F3. Однако если по каким-то причинам функциональная клавиатура не
работает, вместо нее можно использовать комбинацию Esc + соответствующая цифровая
клавиша. Например, F2 заменяется на последовательность Esc 2.
После каждого блока вопросов показывается сводная таблица, которую можно либо
подтвердить, либо перейти назад и исправить то, что ранее было указано неправильно.
Первый же вопрос – выбор раскладки клавиатуры. Он касается только процесса инсталляции,
поэтому можно ограничиться us_EN. Раскладки, которые будут использоваться после
установки, конфигурируются позже.
Выбор языка. Это язык, на котором с вами будет разговаривать инсталлятор. Русского, к
сожалению, еще нет (впрочем, если вам достался дистрибутив OpenSolaris, выпущенный в
2008 году, build 79a и более свежие, то русский язык уже есть; возможно, вам будет
интересно посмотреть, понятно ли переведены сообщения установщика).
Следующий вопрос – будет ли компьютер работать с сетью. В принципе, можно ответить
«нет» и пропустить весь блок вопросов про сеть. После сетевой интерфейс можно будет
настроить вручную. Однако я рекомендую сказать «да», чтобы инсталлятор настроил сетевую
карту сам.
Далее следует вопрос про использование протокола DHCP для получения сетевых установок.
В случае стационарного компьютера ответ зависит от того, как у вас настроено сетевое
окружение. Для компьютера я рекомендую сказать «да» даже если он не подключен к сети
вообще, просто чтобы пропустить дальнейшие вопросы про сеть. Все равно реальные
конфигурации сетевых сервисов будут производиться позже.
Если же вы ответили «да», то вас ждет блок вопросов про настройку сети. В частности – имя
машины, IP-адрес, маску, маршрутизатор. После этого конфигурация сети закончена.
Просмотрим сводную табличку. Все в порядке? Пошли дальше.
Kerberos. Ну, это как хотите. Если нужен, включите.
Сервисы имен. Опять же по историческим причинам инсталлятор предлагает выбрать только
один сервис из набора nis (yp), nis+, dns и ldap или отказаться от этого сервиса вообще.
Однако это не значит, что Solaris может пользоваться только одним. Для стационарного
компьютера – выбираете один из доступных в вашей сети, а остальные можно будет
настроить позже, и в файле /etc/nsswitch.conf задать порядок их использования. Для
компьютера отказываемся от этого вообще. Эти сервисы мы будет настраивать позже и
другими инструментами.

9
NFS4. Оставляем как есть. Опять же, если это стационарный компьютер у вас в локальной
сети есть NFS4, то можете и настроить.
Дальше можно выбрать временную зону, причем как по отклонению от GMT так и выбором
географического региона, и установить время.
После этого надо ввести пароль для пользователя root. Естественно, два раза. Этап под
названием «идентификация системы» завершен. Далее следует собственно процесс
установки.
Установка может осуществляться двумя способами – Standard и Flash. Standard – с диска,
Flash – с флэш-архива. Поскольку этого архива у нас под рукой нет, а диск есть, выбираем
Standard.
Далее подряд идут два вопроса о поведении системы после установки: открыть ли привод с
диском автоматически и перегрузить ли системы автоматически. Отвечать на них надо так:
открыть привод автоматически, перегрузить вручную. Причины для этого следующие. Во-
первых, загрузчик на диске не имеет в меню пункта «загрузиться с жесткого диска» (как это
есть в большинстве дистрибутивов Linux), а при этом на многих компьютерах по каким-то
причинам не удается автоматически открыть DVD-привод. В результате если система
перезагрузится автоматически, то она опять загрузится с DVD и опять попадет в инсталлятор,
а это совсем не то, что нам надо. Поэтому лучше всего мы лично убедимся, что установка
завершена, и лично же нажмем кнопку «перезагрузить».
Теперь на экране появится лицензия. Желательно согласиться с ней, иначе на этом
инсталляция и кончится.
Выбор поддержки географического региона. А вот тут уже имеет смысл выбрать то, что надо,
Россию, например, потому что это список тех локализаций, которые будут устанавливаться.
Пусть не пугает надпись про ISO8859-5, реальная кодировка выбирается в другом месте. А
поставлены будут четыре: ANSI 1251, ISO8859-5, KOI8-R и UTF-8. Mac-кодировки в Solaris
нет.
На следующей странице выбор умолчательной локализации – в которой система будет
грузиться. В принципе, все это может быть настроено и позже. Так что выбирайте то, что
нравится.
Дополнительные продукты пропускаем.
Выбор уровня наполнения. Это предопределенные наборы пакетов. Уровней пять. Про
полный все понятно. Уровень для разработчика – без некоторых серверов. Уровень для
конечного пользователя не содержит include-файлов и библиотек для разработки. Следующий
уровень не содержит графической среды. Минимальная установка – вообще чистый клиент
без серверов.
Далее переходим к разметке диска. Сначала – выбор физического.
Первым делом система предлагает либо использовать весь диск (тогда она просто снесет все
разделы и создаст свои). Предложение делается по умолчанию, но пугаться его не стоит,
нужно выбрать второй пункт – поработать с разделами самому.
Далее, как уже говорилось, если есть пустое место, то на нем можно создать раздел Solaris.
Размер можно указать как в Mb так и в цилиндрах. Не обязательно занимать все свободное
место. А вот внутри расширенных разделов Solaris жить пока не умеет. Однако может удалить
любой раздел, в том числе и расширенный.
Возвращаемся в выбор диска. Диск с разделом Solaris уже помечен.

10
Далее - Layout. Это разбиение раздела Solaris на логические разделы – слайсы (слои). Его
можно сделать как автоматически, так и вручную, и тогда все поля придется заполнять
самому. Я рекомендую выбрать автоматическую раскладку, то уже внутри нее можно выбрать
пункт «customize» (настроить) и поправить так, как вам хочется.
Несколько слов о том, как подправлять. Итак, слайс номер 2 – overlap – просто оставить так
как есть. Это служебный, и его размер совпадает с размером всего Solaris-раздела. Корень –
слайс номер 0. Автораскладка определяет его размер пропорционально всему разделу и
исходя из минимальных требований системы соответственно выбранному набору
программного обеспечения. Но при этом следует помнить, что все пакеты ставятся в /opt,
так что если у Вас большие планы на установку дополнительных пакетов, имеет смысл этот
факт учесть. Swap всегда предлагается один и тот же, чуть больше полугигабайта,
теоретически может отсутствовать вообще. Идеальным являетя размер совпадающий с ОЗУ.
Впрочем, если у вас другие взгляды на необходимый размер swap или специальные
требования к системе – исходите из них. Слайс номер 7 – /export/home. Мой личный
совет – монтировать его не на /export/home, а просто на /export. Так удобнее. Также
можно сделать на отдельных слайсах /var (полезно для серверов с большим количеством
логов), /opt (чтобы ставить все пакеты в специально отведенное место, не пересекающееся
с корнем и домашними каталогами). Также какое-то пространство можно выделить, но не
приписывать к какой-то конкретной точке монтирования, потом этот слайс можно будет
использовать под ZFS, например.
Опять же, стоит отметить, что для компьютера все это может быть не сильно важным, и
достаточно иметь только swap и корень.
Далее инсталлятор спросит про монтирование удаленных сетевых дисков с дополнительным
программным обеспечением (уже установленным, естественно). Он пропишет это в
/etc/vfstab и будет автоматически монтировать при загрузке системы. Нужно для
стационарных станций, которые берут /usr/local или инфраструктуру GRID из одного
места. Для компьютера просто пропускаем.
Последний раз взгляд на сводную таблицу. Все в порядке? Жмем «begin installation» и идем
пить кофе. Для установки с DVD это около 40-50 минут.

Первый запуск
При первом запуске Solaris сначала настроит smf-сервисы (Service Management Facility),
отобразив на экране прогресс этой настройки. Потом запустит графическое приглашение.
Теперь можно начинать работать.
Естественно, первый раз зайти можно будет только под пользоветелем root, ведь других
пользователей еще не создано. Что и рекомендуется проделать при первом запуске – зайти и
создать.

Куда делись другие операционные системы?

Если на компьютере была установлена Windows, то она никуда не делась. Solaris нашел ее и
добавил соответствующую строку в настройку меню загрузчика GRUB.
В случае с BSD системами нужно сделать все по образу и подобию Windows: добавить в
/boot/grub/menu.lst строки вида:
title BSD
root (hd0,n)

11
chainloader +1
где n – номер раздела, на котором стоит BSD.
В случае Linux надо добавить в файл /boot/grub/menu.lst строки, заботливо
скопированные из такого же файла на Linux перед началом инсталляции. Однако если вы
захотите восстановить загрузчик от Linux, сделав его первичным, то стоит помнить, что
GRUB, поставляемый с Linux, не знает ничего о файловой системе Solaris, и директиву
kernel выполнить не сможет. Чтобы загрузить Solaris из под Linux, надо использовать
директиву chainloader.
Теперь рассмотрим случай, при котором перед установкой удалялся Linux swap. Для его
восстановления надо загрузиться в GRUB, выбрать командой root диск, на котором стоит
Linux, и загрузиться с него вручную (последовательность kernel, initrd, boot). После
этого запустить fdisk или gparted и восстановить Linux swap на заранее оставленном для этого
месте. И, наконец, в файле /etc/fstab написать новые номера разделов (после операций
удаления и создания заново нумерация может измениться). Работоспособность Linux
восстановлена.
Теперь вы видите все операционные системы, установленные на вашем компьютере.

Доводка
Управление сетевыми подключениями.
В исходной установке Solaris управление сетевыми подключениями довольно статично. Оно
и понятно, ведь изначально Solaris проектировался как ОС для стационарных рабочих
станций. И даже динамическое получение IP-адреса по протоколу DHCP (с помощью
команды ifconfig <интерфейс> dhcp) действительно динамически работает только с
IP-адресом. А вот динамически же настроить NIS, DNS или другие службы имен оно уже не в
состоянии, поскольку это низкоуровневая команда, предназначенная для управления именно
сетевыми интерфейсами, но никак не сервисами, которые с этими интерфейсами могут быть
связаны.
Однако для Solaris есть инструмент, который помогает решить и эту задачу. Называется он
inetmenu, и расположен он тут:
http://www.opensolaris.org/os/community/laptop/inetmenu/
После его установки нужно удалить из системы некоторые файлы, например,
/etc/hostname.<интерфейс>, /etc/resolv.conf, поскольку они будут
генерироваться корректно при соответствующем сетевом подключении). Сам инструмент
позволяет создавать профайлы и переключаться между ними на лету.
В данный момент inetmenu поддерживает статическое задание IP-адреса, маршрутизации и
сервисов имен, динамическое получение по DHCP и настройку IP-адреса, маршрутизации и
сервисов имен, работу с беспроводной сетью.
Индикатор заряда аккумулятора.
Еще один момент, на который Вы наверняка обратите внимание – отсутствие индикатора
батарейки. Попытка найти его в списке апплетов для gnome будет безуспешной – его там нет.
Но это не значит, что его нет вообще.
Для установки данного апплета (а также некторых других полезных компонент) нужно
воспользоваться специальным инструментом, который называется frkit. Данный
инструмент разработан сообществом Laptop на opensolaris.org и предназначен для загрузки и

12
управления модулями, специфичными именно для компьютеров.
В данный момент в наборе всего 4 модуля:
• acpidrv
• gnome battery applet
• powerdown
• gnome emi-freq applet
Страница, посвященная данному инструменту, расположена здесь:
http://www.opensolaris.org/os/community/laptop/frkit/
После загрузки скрипта и его запуска вышеуказанные модули будут добавлены в систему, и
после этого можно добавить индикатор заряда батареи на панель. Также с их помощью
можно настроить функции засыпания. Замечу только, что в настоящий момент эти функции
работают только для платформы AMD, поддержка платформы Intel планируется.
Драйверы устройств.
По разным причинам (в основном лицензионного характера) в мире существует гораздо
больше драйвером устройств для Solaris, чем содержится в дистрибутиве.
В первую очередь я опять сошлюсь на страницу со ссылками на драйвера сторонних
производителей: http://www.sun.com/bigadmin/hcl/indexRes.html. Для большинства наиболее
популярных моделей компьютеров этой страницы хватает для того, чтобы найти драйвера для
всех устройств. Исключение все еще составляют встроенные устройства для чтения flash-
карт.
Если по какой-то причине Solaris не нашел драйвера для беспроводной карты, рекомендую
посетить страницу http://www.opensolaris.org/os/community/laptop/wireless/. Возможно, Вам
удастся доработать напильником то, что не осилил базовый инсталлятор.
В самом крайнем случае могу посоветовать воспользоваться ndiswrapper. Он позволяет
использовать Windows-драйвера под ОС Solaris.
Рекомендую обратить внимание на такой сайт как http://www.opensound.com/download.cgi. Там
есть OSS драйвера и для Solaris 8/9, и для Solaris 10/OpenSolaris, причем как для Sparc-
платформы, так и для x86. Стоит отметить, что пакет поддерживает большое количество
аудио-карт, многие из которых все еще не поддержаны в Solaris. Недостаток этого пакета – он
не просто закрытый, он еще и платный. Однако тестовый период составляет полгода. А
несомненным достоинством является то, что это настоящий Open Sound.

Дополнительные источники пакетов

Во-первых, большое количество пакетов, не входящих в основную установку Solaris,
распространяется Sun Microsystems совершенно свободно. Их можно найти по адресу:
http://www.sun.com/software/solaris/freeware/index.xml.
Еще один интересный проект – это http://blastwave.org. В рамках этого проекта реализована
надстройка над принятой в Solaris системы пакетирования, которая позволяет устанавливать
пакеты с сетевых репозиториев и отслеживать их версии и зависимости. Вся надстройка
состоит из команды pkg-get, которая устанавливается отдельным пакетом, после чего
установка нового программного обеспечения становится весьма легким мероприятием.
Ну и напоследок снова повторю, что творческое использование поисковых систем иногда

13
творит чудеса.

Управление пользователями

Зачем распределять пользователей по группам?

В Solaris есть ряд предопределенных групп. Большинство из них созданы для запуска
системных процессов от имени этих групп. Одна из групп – staff – предназначена для того,
чтобы ее членами были все обычные пользователи, которым разрешена интерактивная работа
с системой Solaris. Некоторые приложения (например, sendmail или СУБД Oracle) требует
создания специфических групп с определенными именами. При необходимости вы можете
создать новую группу и назначить ее в качестве главной или дополнительной группы тем
пользователям, которым следует делегировать некие одинаковые (для группы) права.

Группа staff часто является главной группой большинства пользователей.

При добавлении пользователя с помощью команды useradd пользователь попадает в

группу other, если явно не указано иное. Эта группа имеет идентификатор 1.

При необходимости изменения учетной записи пользователя следует воспользоваться

программами управления этими записями. Они описаны ниже в разделе «Программы
управления учетными записями пользователей».

Когда вы планируете распределить пользователей по группам, удобно назначить им в

качестве главной группы такую, которая бы соответствовала их основной роли в системе.
Например, те пользователи, чья работа с системой будет ограничена получением почты из
почтовых ящиков, должны быть отнесены к группе pop3 или imap4. Удобно дать таким
группам имена, по которым вы сразу можете вспомнить, ради чего эта учетная запись вообще
появилась в системе.

Представьте: после четвертой чашки кофе ваш взгляд упирается в файл /etc/passwd и в
мозгу начинает неотвязно биться мысль: нет ли в системе лишних пользователей? Может
быть, завалялись какие-нибудь устаревшие учетные записи и их можно вычистить? Открыв /
etc/passwd вы видите несколько сотен пользователей, полтора года назад отнесенных к
группе pop3. Ага, догадываетесь вы, эти забирают почту с нашего сервера. А вот эти, из
группы oldlamer, что тут делают?

После того, как пользователям назначена главная группа, каждый из них может быть
добавлен в другие группы. Все группы, кроме главной, в которых участвует пользователь,
называются дополнительными для этого пользователя. Для добавления пользователя в
дополнительные группы следует использовать программы управления учетными записями.
Эти программы изменят файл /etc/group, так как именно этот файл хранит информацию о
дополнительных группах пользователей. С другой стороны, вы можете вручную исправить
запись о группе в /etc/group, указав в ее последнем поле через запятую тех
пользователей, которых собираетесь добавить в эту группу, вот так:

sys::3:root,bin,adm,skomorox

14
Концепция безопасности UNIX
Вся система безопасности UNIX изначально строилась на трех китах: разделение всех
пользователей по отношению к объекту на владельца объекта, группу объекта и всех
остальных, назначение им прав доступа по-отдельности и обязательное наличие у каждого
объекта владельца и группы.

В современных системах UNIX для большей гибкости прав доступа введены дополнительные
свойства объектов, такие как флаги для файлов и каталогов, списки управления доступом
(ACL) для файлов и каталогов, аутентификация и авторизация с использованием различных
служб аутентификации подобных TACACS и RADIUS, а также модули аутентификации и
авторизации (pluggable authentication modules - PAM).

Естественно, надежность усовершенствованной системы безопасности снизилась, а

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

Тем не менее, для начала познакомимся с классической концепцией безопасности, так как все
остальные дополнения представляют собой лишь надстройку над ней.

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

Разделение всех пользователей по отношению к объекту

У каждого объекта есть владелец. Это – один из пользвателей данной системы UNIX.
Появление объектов, которыми владеют пользователи, не зарегистрированные в данной
системе – это ошибка системного администратора. Такое может произойти при
разархивировании файла, созданного в другой системе. Если вместе с файлом была
сохранена информация о его владельце, то легко может оказаться, что в другой системе есть
пользователь с таким идентификатором (UID), а в нашей – нет.

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

в чужой системе есть пользователь ivan с UID, равным 1000, а в нашей ivan имеет UID,
равный 2001, то при переносе файла с чужой системы к нам с сохранением информации о
владельце файла, в нашей системе появится «бесхозный» файл, если у нас нет пользователя с
UID 1000, или принадлежащий тому пользователю, чей это UID, если такой найдется.

Право владения объектом в UNIX передается по наследству от процесса к процессу, а при

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

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

15
пароль он сообщает программе login. Она работает от имени root (т.е. ее владельцем является
пользователь root). Но программа login запускает для пользователя командный интерпретатор
так, чтобы владельцем процесса командного интерпретатора был сам входящий в систему
пользователь.

Любой объект имеет не только владельца, но и группу. Иногда владельца называют

«хозяином», а группу – «группой владельца», «групповым владельцем», «групповым
хозяином» и т.п. Смысл этого понятия в том, что каждому объекту в UNIX сопоставляется не
только UID (user identificator), который идентифицирует владельца объекта, но и GID (group
identificator), который идентифицирует группу пользователей, имеющую особые права на
объект.

Таким образом реализуется разделение всех пользователей по отношению к объекту на

владельца объекта, группу, имеющую особые права на объект и всех остальных. Группу,
обладающую особыми правами на объект, мы будем называть группой объекта.
Соответственно, мы будем говорить о группе файла, группе каталога или группе процесса.
При этом надо помнить, что группа файла – это не группа, в которую входит файл или его
владелец. В общем случае это – произвольная группа, объединяющая произвольных
пользователей и имеющая особые права на этот объект.

Назначение прав доступа по-отдельности

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

Последних в документации и профессиональных разговорах иногда называют world («мир»),

имея в виду «вообще всех остальных пользователей этого компьютера». Этот термин
происходит из далеких времен, когда компьютеров было мало, а пользователей у одного
компьютера – очень много, и администратор мог гордо говорить о них – «мой мир».

Каждый объект имеет владельца и группу

Любой файл, каталог или процесс имеет владельца и группу. Это означает, что файлу,
каталогу и процессу обязательно сопоставлены два идентификатора, которые называются
UID (user ID) и GID (group ID) соответственно. Администрировать систему легче, если все
объекты имеют UID и GID из числа представленных в /etc/passwd и /etc/group соответственно.
«Бесхозные» объекты вносят сумятицу в стройные ряды прав доступа и делают права
доступа к ним владельца и группы бессмысленными, ведь никто из пользователей не может
получить «чужое» право доступа.

Структура файлов /etc/passwd, /etc/shadow, /etc/group

Файлы /etc/passwd и /etc/group в Solaris имеют такой же формат, как и в других системах
UNIX, а файл /etc/shadow одинаков для всех систем ветви System V. Рассмотрим примеры
файлов (для этого потребуется посмотреть содержимое упомянутых файлов командой cat
или командой more):

16
Учетные записи пользователей

cat /etc/passwd

root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:
col:x:100:1::/home/col:/bin/sh
temp:x:101:1::/home/temp:/bin/sh
qaz:x:102:1::/home/qaz:/bin/sh
Termos:x:103:1::/home/Termos:/usr/bin/bash

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

Первое поле – имя пользователя в системе. Это имя пользователь вводит для входа в систему.
Имя в Solaris должно иметь длину от 2 до 8 символов и содержать только латинские буквы и
цифры. Имя пользователя в Solaris может содержать прописные латинские буквы, однако, из
соображений совместимости с другими системами UNIX, рекомендуется использовать только
строчные (маленькие) буквы.

Второе поле – признак наличия пароля. Пустое поле означает отсутствие пароля. Для
фактического отсутствия пароля у пользователя необходимо, кроме того, чтобы второе поле в
файле /etc/shadow в описании этого пользователя имело значение NP.

Третье поле – идентификатор пользователя, UID.

Четвертое поле – идентификатор главной группы пользователя, GID.

Пятое поле (иногда его называют GECOS) – описание пользователя. Обычно оно содержит
полное имя пользователя (имя и фамилию) и координаты для связи с ним – номер офиса,
адрес, телефон или пейджер.

Шестое поле – домашний каталог пользователя. При интерактивном входе в систему

пользователь попадает именно в этот каталог сразу после успешного входа. Кроме этого,
некоторые сетевые службы (например, ftpd) требуют, чтобы у каждого пользователя,
пытающегося получить доступ к сетевой службе, был «честный», т.е. на самом деле
существующий и доступный для пользователя домашний каталог.

Седьмое поле – командный процессор, который будет запущен для пользователя при
интерактивном входе в систему. Некоторые сетевые службы (например, ftpd) требуют, чтобы
у каждого пользователя, пытающегося получить доступ к сетевой службе, был
существующий в системе на самом деле командный процессор. Файл /etc/shells описывает

17
доступные в системе командные процессоры, которые следует назначать пользователям.
Сразу после установки системы файл /etc/shells не существует. Системный администратор
должен создать его вручную, если он требуется для каких-то программ в системе, например,
для ftpd.

Относительно содержания поля GECOS следует сделать несколько замечаний.

Поле GECOS часто называют полем комментария, и это верно: в нем следует записывать
контактную информацию о пользователе. Системному администратору ничего не скажет
строка в файле протокола, свидетельствующая о проблеме, вызванной работой пользователя
ikonst34. Кто это? Иван Константинович из планового отдела или Илья Константинов из
технического? Или это Иконников Станислав из филиала 34? Чтобы не мучаться
ассоциациями, навеянными именем пользователя, а точно знать, кто скрывается за
лаконичным username, следует заполнять поле комментария.

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

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

Не всегда требуется указывать всю эту информацию. На деле достаточно указать ровно
столько сведений, сколько достаточно системному админитсратору для однозначной
идентификации владельца учетной записи. Пожалуйста, только имейте в виду – не одному-
единственному конкретному системному администратору, а любому администратору,
которому придется управлять созданной вами системой. Вдруг нынешний системный
администратор уволится или уедет в отпуск? Сможет ли его преемник или заместитель
быстро разобраться в записях в /etc/passwd? Делайте записи в поле комментария полезными
сведениями, а не отписками.

Например, можно ожидать нечто вроде следующих записей в /etc/passwd:

root:*:0:0:Root – Michael Kruglov, room 601, 89119119111:/root:/bin/bash

ftp:*:23:1:FTP Admin, Andrei Nezvanyi, 9733333:/home/ftp:/bin/bash
apache:*:404:40:Web Master, Elena Osatanenko,1001010:/usr/local/httpd:/bin/sh

Последнее, что следует сказать о поле GECOS: почему оно так называется.

В свое время компания General Electric владела компьютером, операционной системой

которого была GECOS (General Electric Comprehensive Operating System). Компьютеры под
управлением UNIX использовались для подготовки задач печати для этого компьютера.
Изначальным назначением поля комментария было хранение идентификационной
информации для задач, которые были предназначены для системы GECOS.

18
cat /etc/shadow

root::6445::::::
daemon:NP:6445::::::
bin:NP:6445::::::
sys:NP:6445::::::
adm:NP:6445::::::
lp:NP:6445::::::
uucp:NP:6445::::::
nuucp:NP:6445::::::
smmsp:NP:6445::::::
listen:*LK*:::::::
nobody:NP:6445::::::
noaccess:NP:6445::::::
nobody4:NP:6445::::::
col:9NvfZSaIQgcQk:12435::::::
temp:*LK*:::::::
qaz:v.srD227fHRx2:12448::::::
Termos:o3HzHXFopdwbU:::::::

Этот файл тоже описывает пользователей. В нем хранятся зашифрованные пароли

пользователей. Формат файла таков:

Первое поле – имя пользователя

Второе поле – зашифрованный пароль, *LK* означает, что учетная запись заблокирована
(locked), а NP – что пароль отсутствует (no password).
Третье поле – число дней между 1 января 1970 года и датой последнего изменения пароля
Четвертое поле – минимальное количество дней, которое должно пройти от одной смены
пароля до другой
Пятое поле – максимальное количество дней, которое пароль считается действительным; по
истечении этого количества дней система попросит ввести новый пароль, так как старый
утратит силу
Шестое поле – количество дней, за которое система предупредит пользователя о
необходимости смены пароля
Седьмое поле – количество дней, которое пользователь может не работать в системе и
считаться активным; по истечении этого количества дней учетная запись автоматически
блокируется
Восьмое поле – дата, до которой учетная запись считается действительной; после этой даты
пользователь не сможет войти в систему
Девятое поле зарезервировано и сейчас не используется.

Данный формат /etc/shadow характерен как для Solaris, так и для других подобных System V
систем UNIX, например, для Linux.

В /etc/shadow обязательно присутствуют только первые три поля в каждой записи, остальные
могут отсутствовать – все или часть из них. Рекомендуется не вносить исправления в
/etc/shadow вручную, а делать это с помощью программ smc, usermod, useradd, passwd.
Однако, в одном случае – если вы забыли пароль root – придется исправлять /etc/shadow в
текстовом редакторе.

19
Пользовательские файлы конфигурации

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

присутствуют файлы конфигурации командного процессора. Если в системе используется
несколько командных процессоров, имеет смысл сделать такие файлы конфигурации для
каждого из них; о разных файлах конфигурации командных процессоров см. лекцию 11.
Кроме них, могут быть файлы конфигурации графической среды (.Xsession и другие), файлы
конфигурации почтовой системы (.elm, .forward и другие), файлы с историей команд
(.history, .bash_history) и прочие. Их объединяет то, что их имена практически всегда
начинаются с символа «.» (точка). Можно увидеть их в списоке файлов каталога, если дать
команду

ls -a

Пользовательские файлы конфигураций создаются заранее системным администратором

.Стандартные пользовательские файлы конфигураций по умолчанию поставляются вместе с
операционной системой и в Solaris располагаются в /etc/skel (от слова skeleton – скелет, т.е.
основа). При создании нового пользователя они автоматически копируются из каталога
/etc/skel в домашний каталог нового пользователя. При создании нового пользователя или
модификации существующей учетной записи можно указать другой каталог с файлами
конфигурации, чтобы копировать не файлы по умолчанию, а другие файлы. Их
предварительно следует создать и модифицировать в соответствии с желаемыми настройками
для новых пользователей.

Модификация файлов в каталоге /etc/skel повлияет только на настройки новых

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

Мы будем далее называть /etc/skel каталогом базовых пользовательских файлов

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

Группы пользователей
Группы, определенные в системе, перечислены в файле /etc/group. В системе могут быть
определены и другие группы, если для аутентификации и авторизации помимо файлов
/etc/passwd и /etc/group используются и другие источники (например, каталог LDAP).

cat /etc/group

root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
sysadmin::14:

20
smmsp::25:smmsp
nobody::60001:
noaccess::60002:
nogroup::65534:

Первое поле – имя группы.

Второе поле – зашифрованный пароль; это устаревшее поле, в настоящее время нет команды,
которая бы позволила установить пароль на группу и обычно нет необходимости это делать.
Если все же такая необходимость появится, то можно установить требуемый пароль какому-
нибудь пользователю с помощью программы passwd, а затем копировать поле пароля из
/etc/shadow в /etc/group. Пароль группы используется в Solaris только программой newgrp. Эта
программа требуется для изменения эффективного группового идентификатора пользователя
в ходе его интерактивной работы. Если группа, которой соответствует новый групповой
идентификатор, имеет пароль, то программа newgrp его запросит.

Третье поле – идентификатор группы (GID). Этот идентификатор должен быть уникальным в
пределах системы, а в случае использования общих файлов групп и паролей – в пределах
всей сети организации. Номера от 0 до 99 и от 60001 до 60002 зарезервированы для
системных групп. Создавайте свои группы с идентификаторами от 100 до 60000
включительно.

Четвертое поле – список пользователей через запятую; для этих пользователей данная
группа будет являться дополнительной. В Solaris принято по умолчанию, что один
пользователь может принадлежать не более чем к 15 дополнительным группам.

Программы управления учетными записями пользователей

Для управления учетными записями следует использовать программу smc при работе в
графическом режиме или программы useradd, usermod, userdel, groupadd, groupmod, groupdel в
текстовом режиме или в окне терминала.

Рис. 1: Окно устаревшей программы admintool

21
Solaris Management Console
В системах Solaris 9 (до мая 2002 года) для управления учетными записями пользователей
было возможно использовать программу admintool (рис. 1). В системах Solaris 8 и более
ранних программа admintool также использовалась для управления пакетами ПО. Сейчас
программа admintool считается устаревшей и в состав системы не входит. Вместо нее следует
использовать Solaris Management Console (SMC).

Здесь достаточно посмотреть, как именно можно управлять пользователем в smc (рис. 2).

Рис. 2: Окно Solaris Management Console

Выбрав из списка одного пользователя (рис. 3), можно установить любые из свойств,
перечисленных выше, при рассмотрении формата файлов /etc/passwd, /etc/shadow и /etc/group.
Если же вы хотите добавить пользователя, следует воспользоваться кнопкой “Add user with
Wizard”.

Любая программа типа smc для работы со свойствами учетной записи пользователя в
графическом режиме, все равно вызывает простые системные программы с интерфейсом
командной строки для выполнения любых операций с этими свойствами. В Solaris для
создания новой учетной записи пользователя (добавления пользователя в систему)
используется программа useradd, для модификации учетной записи пользователя - usermod,
для удаления учетной записи - userdel.

22
 Рис. 3: Управление учетными записями с
помощью Solaris Management Console (smc)
useradd

Для добавления нового пользователя из командной строки без использования smc следует
выполнить команду useradd.

При добавлении пользователя с помощью команды useradd пользователь попадает в группу

other, если явно не указано иное. Эта группа имеет идентификатор 1.

При добавлении пользователя в Solaris происходит добавлении соответствующей строки в

файлы /etc/passwd, /etc/shadow и /etc/user_attr. Первые два файла нам уже знакомы. Последний
служит для записи дополнительных атрибутов пользователя. Он используется только в
Solaris, в других системах UNIX такого файла нет. К дополнительным атрибутам относятся
административные права, данные этому пользователю, перечень ролей, назначенных
пользователю, и указание на то, является ли эта учетная запись пользователя информацией о
реальном пользователе или информацией о роли.

По умолчанию useradd добавляет учетную запись пользователя в файлы /etc/passwd и

/etc/shadow. Кроме этого, при указании ключа –G запись о пользователе помещается в
/etc/group в строку тех групп, которые указываются в качестве дополнитлеьных для него. С
помощью ключа –m можно указать, что для пользователя следует создать домашний каталог.

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

пользователю не будет назначен пароль с помощью программы passwd.

Имя пользователя или роли не может быть длиннее 8 символов, и должно содержать только
латинские символы, цифры, точку, знак подчеркивания и дефис. Точка является допустимым
символом не для всех систем UNIX, поэтому ее не рекомендуется использовать в Solaris в

23
 целях совместимости, хотя это требование не является жестким. Первый символ имени
должен быть буквой, по крайней мере одна буква в имени должна быть буквой нижнего
регистра.

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

задаются по умолчанию в отсутствие этих ключей:

-b base_dir
каталог, в котором должен быть создан домашний каталог пользователя; не требуется
указывать, если используется ключ –d

-c comment
поле GECOS общей информации о пользователе, как минимум, следует указать полное
имя пользователя
-d dir
домашний каталог пользователя; по умолчанию создается в каталоге /home и носит то
же имя, что и пользователь (для пользователя lena создается домашний каталог
/home/lena)

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

Значения по умолчанию, принятые в системе, перечислены в Табл. 1

группа other (GID =1)
каталог с домашними каталогами /home
пользователей
командный процессор /bin/sh
профиль не назначается
роль не назначается

Табл. 1 Значения свойств учетной записи пользователя по умолчанию

-e expire
дата истечения срока действия учетной записи; формат даты определен, как
рассказано в man 3C getdate; по умолчанию не задано, после наступления этой даты
пользователь не сможет войти в систему; используется для создания учетных записей
временных сотрудников или гостей

-f inactive
максимальное число дней, в течение которых пользователь может не входить в
систему, по истечении этого срока учетная запись блокируется; удачное решение для
забывчивых системных администраторов, которые не удаляют учетные записи при
увольнении сотрудника, позволяет бороться с накоплением «мертвых душ в системе»

-g group
главная группа пользователя, по умолчанию – other; подробности настройки групп по
умолчанию см. в man useradd

24
-k skel_dir каталог с базовыми пользовательскими файлами конфигураций, указанный
каталог должен существовать, копии всех содержащихся в нем файлов будут помещены в
домашний каталог нового пользователя. По умолчанию - /etc/skel.

-m требует создать домашний каталог нового пользователя; если каталог уже есть, у главной
группы пользователя должно быть право на чтение, запись и поиск в этом каталоге.

-o разрешить пользователю иметь uid, совпадающий с uid существующего пользователя;

может использоваться для дублирования учетной записи root. Это может понадобиться для
того, чтобы от имени пользователя root входить в систему только в экстренных случаях, а
обычно пользоваться другой учетной записью. Во FreeBSD для этого по умолчанию
предоставляется учетная запись toor (root наоборот). Это может быть удобно, например, для
назначения администратору командного процессора, отличного от /bin/sh, например,
/usr/local/bin/bash. Назначить такой командный процессор пользователю root нельзя, т.к. его
командный процессор должен работать даже тогда, когда доступна только файловая система /,
а /usr даже не смонтирована.

-s shell полное имя файла, который будет назначен пользователю в качестве командного
процессора при входе в систему; файл должен существовать

-u uid
явное указание значения UID.

Для изменения свойств пользователя следует запускать программу usermod. Ее синтаксис

предполагает явное задание изменяемого свойства, а не интерактивного взаимодействия. При
запуске без ключей только с указанием имени пользователя, чью учетную запись мы желаем
изменить, программа usermod выдает сообщение об ошибке и краткую подсказку по
использованию:
usermod ivan
UX: usermod: ERROR: Invalid syntax.
usage: usermod -u uid [-o] | -g group | -G group[[,group]...] |
-d dir [-m] | -s shell | -c comment |
-l new_logname | -f inactive | -e expire
-A authorization [, authorization ...] |
-P profile [, profile ...] | -R role [, role ...] login

Для удаления пользователя используйте userdel.

Для добавления группы слудет использовать groupadd, для удаления - groupdel; для изменения
учетной записи группы – groupmod.

Управление дисками и файловыми системами. Общий

обзор.

Термин “файловая система”

Термин «файловая система» в литературе используется для обозначения трех разных
понятий:
(1) Во-первых, файловая система – это набор правил и конструкций , описывающих то, как
сохраняются файлы на диске. В этом смысле мы употребляем, например, выражение
«файловая система FAT32», и «файловая система» здесь тождественна понятию «тип

25
файловой системы».
(2) Во-вторых, файловая система – это совокупность всех файлов, хранимых в компьютере.
(3) В-третьих, и это значение термина характерно именно для UNIX-систем, файловая
система – это совокупность всех файлов на разделе диска или устройстве, или, что точнее,
файловая система – это логическая единица монтирования (то, что можно смонтировать
командой mount в отдельный каталог дерева каталогов).

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

Две концепции файловой системы в UNIX

В системах UNIX до 2004 года существовала только одна концепция файловых систем,
основанная на представлении файловой системы компьютера как единого дерева, отдельные
“ветви” которого могут быть расположены на различных физических носителях или в
различных разделах одного и того же носителя. Концепция предполагала необходимость
разметки любого физического носителя (часто – вручную, т.е. системный администратор
должен был спланировать разметку диска и потратить некоторое время на его разметку с
помощью fdisk, format или аналогичного инструмента).
Эта концепция была эффективна, и прежде всего – для сравнительно малого количества
физических носителей, потому что позволяла при необходимости разбить диск на отдельные
разделы и управлять ими по-отдельности. При увеличении количества носителей
администрировать файловую систему с несколькими разделами на каждом носителе
становилось противно – от администратора требовалась все большая внимательность и все
лучшая память.
В то же время, системные администраторы со временем масштабируются хуже компьютеров –
и внимательность их скорее снижается из-за распыления внимания на новые задачи и
необходимость иметь дело с объектами растущих масштабов.
Для изоляции файлов операционной системы от пользовательских файлов в пределах одного
компьютера можно было разбить жесткий диск на несколько разделов, в одном из которых
разместить файловую систему с пользовательскими файлами. Такая изоляция, с одной
стороны, физически ограничивала возможный рост занятого в файловой системе
пространства размерами раздела, с другой – исключала повреждение файлов вне раздела при
ошибочных или дестуктивных действиях приложения, работающего с конкретной файловой
системой. Кроме этого, физическое повреждение диска в области, где размещен только один
раздел, не оказывало влияния на возможность чтения и записи данных в другом разделе.
С появлением больших дисковых массивов, состоящих из десятков и сотен дисков, особенно
в системах, связанных с высокопроизводительными вычислениями и обработкой больших
объемов данных, потребовалось собирать из физических дисков виртуальные тома. Для этого
разные производители систем испольовали разные приложения, среди которых большую
популярность получил Logical Volume Manager (LVM) для Linux. Однако, хотя использование
LVM облегчало группировку разделов в логические тома большого объема, необходимость
размечать каждый диск и создавать на нем разделы сохранялась.
Поэтому в 2004 году появилась вторая концепция файловой системы, которая тоже
предполагала существования единого логического дерева каталогов, но на уровне
физических устройств требовала создания единого пула, из которого можно выделить
произвольный объем для любой файловой системы (в смысле “логической единицы
монтирования”). Эта концепция представляла дисковую память таким же образом, как

26
вируальную память, в которой работают процессы в UNIX.
В самом деле, когда вы запускаете новое приложение, и оно запрашивает у системы некий
объем памяти для работы, система обходится без указания ей, в каких именно микросхемах
памяти разместить данные и код нового приложения! Так и новая концепция пулов устройств
требовала лишь указания, какие физические устройства (или, если администратор пожелает,
их части) будут входить в пул. После этого вы можете пожелать выделить какой угодно объем
памяти для ваших файлов или файловых систем, и он будет вам предоставлен – если только
хватит места в пуле (понятно, что если у вас есть диск объемом 250 Гб и вы просите
выделить место для записи 500-гигабайтного файла, то места может и не хватить!)
Вторая концепция была впервые воплощена в файловой системе ZFS, разработанной
компанией Sun Microsystems в 2004 году, поддержка которой появилась в Solaris 10. К началу
2008 года код поддержки ZFS был портирован во FreeBSD и Mac OS X Leopard.
Ниже в этой лекции будут рассмотрено строение файловой системы UFS, воплощающее
первую, более старую концепцию файловой системы и типовые задачи, связанные с
администрированием UFS. В следующих двух лекциях будет дано более подробное описание
файловых систем UFS и ZFS соответственно.

Файлы устройств в Solaris

Каждому физическому устройству в Solaris обязательно соответствует файл устройства. Файл

устройства по сути – это указатель на область кода ядра, в которой находится драйвер
устройства. Файлы устройств располагаются в каталоге /dev и его подкаталогах. Такое
расположение является стандартным для всех систем UNIX. Однако на самом деле в Solaris
все файлы в каталоге /dev являются символьными ссылками на «настоящие» файлы
устройств, которые располагаются в подкаталогах каталога /devices. Там эти файлы
сгруппированы по отношению к своему месту в конфигурации компьютера. Подробнее это
рассмотрено ниже в разделе «каталог /devices». О символьных ссылках подробнее рассказано
в лекции 7 в разделе «ссылки».

Файлы устройств имеют специальные типы:

файл символьного устройства
файл блочного устройства

Вывод программы ls иллюстрирует это:

ls -l /devices/pseudo/

...
crw-rw-rw- 1 root sys 26, 0 Мар 17 10:56 ptsl@0:ttyp0
crw-rw-rw- 1 root sys 26, 1 Мар 17 10:56 ptsl@0:ttyp1
crw-rw-rw- 1 root sys 26, 2 Мар 17 10:56 ptsl@0:ttyp2
crw-rw-rw- 1 root sys 26, 3 Мар 17 10:56 ptsl@0:ttyp3
...

ls -l /devices/pci@0,0/pci-ide@7,1/ide@0

...
brw-r----- 1 root sys 102, 0 Мар 17 10:56 cmdk@0,0:a

27
crw-r----- 1 root sys 102, 0 Мар 17 10:56 cmdk@0,0:a,raw
brw-r----- 1 root sys 102, 1 Мар 24 21:19 cmdk@0,0:b
crw-r----- 1 root sys 102, 1 Мар 17 10:56 cmdk@0,0:b,raw
...

Файл устройства является псевдофайлом, он не размещен на диске, о нем есть только запись,
которая используется при доступе к устройству. Первое число, которое стоит в поле длины
файла в выводе программы ls для файлов устройств - это major номер, а второе, после запятой
- minor номер. Первый из них означает номер типа устройств и одновременно - позицию в
ядре, в которой следует искать драйвер устройства. Второй - номер экземпляра устройства
данного типа. Поэтому файлы однотипных устройств в вышеприведенном выводе ls имеют
одинаковые major номера.

Устройство каждого типа имеет свой major номер. Major номера назначаются автоматически
программой add_drv. Соответствие имени драйвера и major номера определяется в файле
/etc/name_to_major.

В Solaris все устройства имеют три имени разных типов: логическое имя, физическое имя и
экземплярное имя.

Логические имена – это имена файлов устройств, которые хранятся в /dev.

Физические имена – это имена файлов устройств, хранящихся в /devices.
Экземплярные имена – это укороченные физческие имена устройств, которые ядро назначает
устройствам.

Ниже рассмотрен пример назначения всех перечисленных типов имен.

файлы устройств для разделов дисков в Solaris

Мы предполагаем, что читатель знаком с физическим устройством жестких дисков, поэтому

здесь не объясняются термины «головка», «дорожка», «цилиндр», «сектор» и другие. Все они
являются общими для описания любых жестких дисков в любых компьютерах, независимо от
архитектуры или используемой операционной системы.

Жесткий диск принято делить на разделы (в Solaris их называют slices). Раздел – это группа
расположенных рядом цилиндров. Смысл разделения диска на разделы состоит в том, чтобы
(1) минимизировать расстояние, которое потребуется головке диска для считывания
фрагментов одного файла,
(2) разделить данные разных типов, чтобы обезопасить системные данные от возможной
порчи пользовательскими программами,
(3) зарезервировать под системные нужды достаточное пространтство на диске так, чтобы
несистемные файлы не могли его занять.

Жесткие диски

В Solaris на одном физическом жестком диске может быть до восьми разделов, которые
принято нумеровать цифрами от 0 до 7.

28
Каждому разделу соответствует свой файл устройства в каталоге /dev/dsk. Пространство под
разделы выделяется цилиндрами. Раздел однозначно определяется номерами начального и

конечного цилиндров. В Solaris принята следующая концепция именования таких файлов

устройств: в имени устройства учитываются номер контроллера, SCSI ID (target number),

номер
диска (LUN – logical unit number) и номер раздела на диске. Если это диск IDE, то роль SCSI
ID играет пара master/slave (соответственно, 0/1). Для встроенных дисков SCSI и любых
дисков IDE номер диска равен 0. Это иллюстрирует рис. 5.

Так, для системы с дисками SCSI /dev/dsk/c0t0d0s0 будет указывать на нулевой контроллер
SCSI (c0), диск со SCSI ID 0 (t0), диск номер 0 на этом SCSI контроллере (d0), нулевой раздел
на этом диске (s0).

Как показано на Рис. 4, при создании файла устройства для раздела, который находится на
IDE-диске, в названии файла учитываются номер адаптера IDE (как правило, в компьютерах
x86 используют системные платы с одним адаптером, который поддерживает два канала IDE),
номер канала (он кодируется как SCSI ID, как показано в табл.Табл. 2), номер диска (всегда
d0) и номер раздела (первый раздел на диске – s0 и т.д., подобно разделам на SCSI дисках).

Рис. 4 Конфигурация с IDE-устройствами

29
номер диска в подсистеме IDE позиция диска в подсистеме IDE

0 primary master
1 primary slave
2 secondary master
3 secondary slave

Табл. 2 Соответствие между SCSI ID и позиции IDE-диска в подсистеме IDE

Сказанное выше о именовании файлов устройств дисков IDE относится к системам на

платформе SPARC. На платформе х86 файлы устройств, соответствующие разделам дисков
IDE, именуются несколько иначе. Файлы, соответствующие разделам fdisk, обозначаются
cNdMpK, где после с идет номер контроллера, после d – номер диска, а после p – номер
раздела fdisk. На каждом из разделов fdisk может быть создано несколько подразделов (slices),
если этот раздел fdisk является разделом типа solaris. Любой раздел fdisk имеет свой тип,
который указывается в таблице Master Boot Record (MBR), в которой опитсаны все разделы
fdisk диска.

По умолчанию при установке Solaris на IDE-диск на платформе IA (x86) программа-

установщик Solaris создает два раздела fdisk – загрузочный (примерно 20 Мб) с программой-
загрузчиком и раздел, на котором будут находиться все остальные части системы, а также
пользовательские файлы. Первый раздел fdisk имеет тип FAT, а второй – тип Solaris. На
втором разделе создаются подразделы (slices). Они именуются подобно таким же разделам на
дисках систем SPARC, но без указания SCSI ID: c0d0s0, c0d0s1 и т.д.

Каждому файлу в каталоге /dev/dsk соответствует файл устройства прямого доступа (raw disk) в каталоге
/dev/rdsk:

# ls /dev/dsk
c0d0p0 c0d0s1 c0d0s15 c0d0s7 c1t0d0p3 c1t0d0s12 c1t0d0s4
c0d0p1 c0d0s10 c0d0s2 c0d0s8 c1t0d0p4 c1t0d0s13 c1t0d0s5
c0d0p2 c0d0s11 c0d0s3 c0d0s9 c1t0d0s0 c1t0d0s14 c1t0d0s6
c0d0p3 c0d0s12 c0d0s4 c1t0d0p0 c1t0d0s1 c1t0d0s15 c1t0d0s7
c0d0p4 c0d0s13 c0d0s5 c1t0d0p1 c1t0d0s10 c1t0d0s2 c1t0d0s8
c0d0s0 c0d0s14 c0d0s6 c1t0d0p2 c1t0d0s11 c1t0d0s3 c1t0d0s9

# ls /dev/rdsk
c0d0p0 c0d0s1 c0d0s15 c0d0s7 c1t0d0p3 c1t0d0s12 c1t0d0s4
c0d0p1 c0d0s10 c0d0s2 c0d0s8 c1t0d0p4 c1t0d0s13 c1t0d0s5
c0d0p2 c0d0s11 c0d0s3 c0d0s9 c1t0d0s0 c1t0d0s14 c1t0d0s6
c0d0p3 c0d0s12 c0d0s4 c1t0d0p0 c1t0d0s1 c1t0d0s15 c1t0d0s7
c0d0p4 c0d0s13 c0d0s5 c1t0d0p1 c1t0d0s10 c1t0d0s2 c1t0d0s8
c0d0s0 c0d0s14 c0d0s6 c1t0d0p2 c1t0d0s11 c1t0d0s3 c1t0d0s9

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

30
Говоря о разных типах имен устройств можно рассмотреть пример именования разделов
диска. Так, разделам SCSI-диска со SCSI ID, равным 6, присоединенному к нулевому
контроллеру, будут соответствовать логические имена устройств (разделов диска) от /dev/dsk/
c0t6d0s0 до /dev/dsk/c0t6d0s7, физические имена от /devices/pci@1f,0/pci@1,1/scsi@6/sd@0,0:a
до /devices/pci@1f,0/pci@1,1/scsi@6/sd@0,0:g. При этом диску в целом будет соответствовать
экземплярное имя sd6.

каталог /devices
Каталог /devices отражает аппаратную конфигурацию компьютера. Дерево его подкаталогов
строится в соответствии с реальными подключениями устройств к шинам и контроллерам.
Поэтому для компьютеров различных архитектур структура дерева подкаталогов /devices
будет разной. Содержание этих подкаталогов будет разным для разных компьютеров, даже
если они имеют одинаковую архитектуру, потому что компьютеры могут иметь разную
конфигурацию: неодинаковое количество жестких дисков, различные контроллеры
интерфейсов (SCSI, IDE), по-разному подсоединенные к ним диски. Например, для
компьютера x86 дерево может быть таким:

./pseudo
./isa
./isa/fdc@1,3f0
./isa/i8042@1,60
./pci@0,0
./pci@0,0/pci8086,7191@1
./pci@0,0/pci-ide@2,1/ide@0
./pci@0,0/pci-ide@2,1/ide@1
./pci@0,0/pci-ide@2,1

Это пример дерева каталогов Solaris 9, установленного на ноутбук IBM ThinkPad 390X.

Полный список всех устройств компьютера, с которыми система Solaris готова работать,
содержится в файле /etc/path_to_inst.

Файл /etc/path_to_inst содержит соответствия физических имен устройств и номеров

экземпляров устройств (тех, что называются minor номерами устройств). Чтобы эти
соответсвия сохранялись от загрузки к загрузке, система записывает их в файл
/etc/path_to_inst. Этот файл во время загрузки доступен только для чтения, он может быть
изменен с помощью программ add_drv(1M) и drvconfig(1M).

Обычно системному администратору незачем изменять этот файл. Для просмотра полного
списка устройств следует использовать команду prtconf:

prtconf

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

prtconf | grep –v not

Это позволяет отфильтровать в выводе prtconf строки, содержащие слово “not”, например,
“device not attached”.

31
Структура файловых систем, соответствующих POSIX

Основные понятия: суперблок, метаданные, точка монтирования

Хотя стандарт POSIX (его свежайшей версией в настоящий момент является IEEE Std 1003.1,
2004 Edition) не предусматривает конкретной реализации стурктур файловой системы, во
всех известных нам файловых системах ОС UNIX (а все они отвечают стандарту POSIX)
присутствуют три сущности: суперблок, метаданные и данные. При этом суперблок
обязательно содержит данные, относящиеся к файловой системе в целом, метаданные
состоят из атрибутов файлов, к которым непрменно относится уникальный номер файла в
файловой системе (его часто называют индексным дескриптором файла), а сами данные
представляют собой файлы – поименованные объекты, расположенные на физическом или
логическом носителе.
Эти сущности могут являться достаточно высоким уровнем абстракции: скажем, в файловой
системе ZFS структуры, физически записанные на диске, заметно сложнее, чем упомянутые
сущности, а в UFS суперблок, метаданные в виде таблицы индексных дескрипторов и файлы
на самом деле размещаются на диске практически без дополнительных вспомогательных
данных.
Общим понятием для всех файловых систем, соответствующих POSIX, также является точка
монтирования. Это – каталог, в котором появляется содержимое логического или
физического раздела файловой системы после его монтирования. Монтирование
представляет собой операцию присоединения “ветви” к дереву файловой системы и
выполняется автоматически программой автомонтирования или по команде mount.

Рис. 5: Дерево и ветвь до Рис. 6: Дерево после

присоединения (монтирования) присоединения ветви
ветви

32
Как видно из рис. 5, до того, как ветвь будет присоединена к файловой системе, должна
существовать и файловая система, и ветвь. Проще говоря, если вы присоединяете новый
носитель к существующей файловой системе, на этом носителе уже должны быть размечены
разделы и содержаться файловая система известного операционной системе типа. Это
происходит, например, когда вы вставляете DVD-диск в привод и желаете его прочесть.
Чтобы содержимое нового диска стало доступным для операционной системы, требуется
произвести операцию “монтирования”, т.е. сообщить операционной системе, в какой каталог
существующей файловой системы следует поместить содержимое нового диска. Этот каталог
называется “точкой монтирования” (на рис. 5 точка монтирования показана красной
стрелкой). После монтирования файловая система приобретает целостный вид, и
пользователю (или стороннему наблюдателю) кажется, что дерево файловой системы
монолитно, хотя на самом деле оно может состоять из нескольких ветвей, каждая из которых
присоединена в свою точку монтировния (рис. 6).
Предположим, что для начала у нас есть только корень дерева (корневой раздел). Мы можем
присоединить к нашей фаловой системе другие разделы. Присоединим еще один раздел (в
нем хранятся какие-то каталоги, но пока он не имеет имени в нашей файловой системе).

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

(точку монтирования) следует смонтировать новый раздел. После монтирования все каталоги
нового раздела будут доступны в качестве подкаталогов точки монтирования. При этом
истинная стурктура файловой системы оказывается прозрачна для пользователя. После того,
как раздел смонтирован, пользователь не отличит каталоги одного раздела от другого.
Посмотреть, какие разделы в какие точки монтирования присоединены, можно командой
mount, которая в разных системах UNIX выдает сведения в разном формате. Ниже мы
обсудим форматы трех систем – FreeBSD, Linux и Solaris.

Обратите внимание на то, что если каталог является точкой монтирования, то он находится
на отдельном разделе, а если нет – то он расположен на том же разделе, что и родительский
каталог. Например, каталог /var в примерах ниже расположен на отдельном разделе, а
каталог /etc – в том же разделе, что и каталог /.

Вот как выглядит информация, выдаваемая mount в разных системах UNIX:

FreeBSD:
mount
/dev/ad0s1a on / (ufs, local)
/dev/ad0s1e on /var (ufs, local, soft-updates)
/dev/ad0s1f on /cache (ufs, local, soft-updates)
/dev/ad0s1g on /usr (ufs, local, soft-updates)
procfs on /proc (procfs, local)

Linux:
mount
/dev/hda1 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hda5 on /usr type ext2 (rw)
/dev/hda6 on /var type ext2 (rw)

33
Solaris:
/ on /dev/dsk/c0d0s0
read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980000 on Пн янв. 14
23:48:38 2008
/devices on /devices read/write/setuid/devices/dev=4380000 on Пн янв. 14 23:48:21 2008
/dev on /dev read/write/setuid/devices/dev=43c0000 on Пн янв. 14 23:48:21 2008
/system/contract on ctfs read/write/setuid/devices/dev=4400001 on Пн янв. 14 23:48:21 2008
/proc on proc read/write/setuid/devices/dev=4440000 on Пн янв. 14 23:48:21 2008
/etc/mnttab on mnttab read/write/setuid/devices/dev=4480001 on Пн янв. 14 23:48:21 2008
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev=44c0001 on Пн янв. 14 23:48:21 2008
/system/object on objfs read/write/setuid/devices/dev=4500001 on Пн янв. 14 23:48:21 2008
/usr on /dev/dsk/c0d0s6
read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980006 on Пн янв. 14
23:48:38 2008
/lib/libc.so.1 on /usr/lib/libc/libc_hwcap2.so.1 read/write/setuid/devices/dev=1980006 on Пн янв. 14
23:48:35 2008
/dev/fd on fd read/write/setuid/devices/dev=4680001 on Пн янв. 14 23:48:38 2008
/var on /dev/dsk/c0d0s1
read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980001 on Пн янв. 14
23:48:39 2008
/tmp on swap read/write/setuid/devices/xattr/dev=44c0002 on Пн янв. 14 23:48:39 2008
/var/run on swap read/write/setuid/devices/xattr/dev=44c0003 on Пн янв. 14 23:48:39 2008
/opt on /dev/dsk/c0d0s5
read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980005 on Пн янв. 14
23:48:44 2008
/export/home on /dev/dsk/c0d0s7
read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=1980007 on Пн янв. 14
23:48:44 2008
/home/filip on /export/home/filip read/write/setuid/devices/dev=1980007 on Вт янв. 15 14:06:53 2008

В Solaris выдается значительно больше информации, чем в Linux и FreeBSD, и если вы

привыкли к более короткому выводу, имеет смысл написать короткий скрипт, который и
вызывать вместо mount каждый раз. Например, это можно сделать так:

Solaris:
mount -p | grep dsk | awk '{print $3 " on " $1 " (" $7 ")"}'
/ on /dev/dsk/c0d0s0 (rw,intr,largefiles,logging,xattr,onerror=panic)
/usr on /dev/dsk/c0d0s6 (rw,intr,largefiles,logging,xattr,onerror=panic)
/var on /dev/dsk/c0d0s1 (rw,intr,largefiles,logging,xattr,onerror=panic)
/opt on /dev/dsk/c0d0s5 (rw,intr,largefiles,logging,xattr,onerror=panic)
/export/home on /dev/dsk/c0d0s7 (rw,intr,largefiles,logging,xattr,onerror=panic)

монтирование и демонтирование файловых систем

При старте системы после загрузки ядра и запуска процесса init инициируется проверка тех
файловых систем, которые следует проверить и смонтировать автоматически. Их список
содержится в файле /etc/vfstab3. Типичный файл /etc/vfstab выглядит так:

#device device mount FS fsck mount mount

#to mount to fsck point type pass at boot options
#
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/dsk/c0d0s1 - - swap - no -
/dev/dsk/c0d0s0 /dev/rdsk/c0d0s0 / ufs 1 no -
/dev/dsk/c0d0p0:boot - /boot pcfs - no -
/dev/dsk/c0d0s7 /dev/rdsk/c0d0s7 /export/home ufs 2 yes -
swap - /tmp tmpfs - yes -

Те файловые системы, которые в столбце mount at boot отмечены как yes, будут проверены и

3 Внимание! В других системах UNIX этот файл имеет другое название - /etc/fstab

34
смонтированы при старте системы. Файловую систему можно смонтировать в любой момент,
надо лишь указать ей в качестве точки монтирования пустой каталог, который уже
существует и доступен в системе. Операцию монтирования и демонтирования файловой
системы может осуществить только root.

Монтирование файловой системы выполняется командой mount:

mount device mount_point

Например

mount /dev/dsk/c0d1s0 /test

Для монтирования файловой системы, которая описана в /etc/vfstab, можно не указывать

имя файла устройства, а сразу указать точку монтирования. Такую «сокращенную» команду
mount можно применять только для монтирования файловых систем, перечисленных в /etc/
vfstab.

При монтировании файловой системы следует явно указывать ее тип, если он отличается от
UFS.

Демонтирование файловой системы делает ее недоступной для чтения и записи, файлы,

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

Нельзя демонтировать занятую файловую систему. Занятой считается такая файловая

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

Чтобы все-таки демонтировать файловую систему, следует найти и устранить причину ее

занятости. Чатсо для этого достаточно просто самому выйти из того каталога, который
собираешься демонтировать. Это типичная ошибка системного администратора: пытаться
демонтировать /usr в тот момент, когда находишься в /usr/admin или подобном
подкаталоге, который лежит в том же разделе, что и /usr.
Демонтирование файловой системы выполняется командой umount:

umount mount_point

Например

umount /mnt

монтирование дискет и прочих сменных носителей

Для монтирования дискет, компакт-дисков и прочих сменных носителей в Solaris имеется
специальная программа vold (Volume Management daemon). Она следит за тем, вставлены ли
компакт-диск, дискета, или, к примеру, zip-диск в соответствующее устройство. Как только
диск оказывается в устройстве, vold вызывает программу volcheck, чтобы проверить,
действительно ли в привод установили новый диск, а затем программу rmmount для
монтирования диска в заранее определенную точку монтирования. Программа rmmount

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

man rmmount

Поведение rmmount определяется файлом конфигурации /etc/rmmount.conf.

Программу rmmount можно запускать и вручную. Кроме того, можно использовать команду
volrmmount для форсирования перемонтирования или демонтирования файловой системы на
сменном носителе. Детали использования следует почерпнуть в man volrmmount.

Суперблок

Таблица индексных дескрипторов

Дерево каталогов
Файлы в UNIX’e разложены по каталогам. Каталоги образуют древовидную структуру: есть
корневой каталог, который обозначается знаком ”/” (слэш), и его подкаталоги. В каждом из
последних есть свои подкаталоги и т.д. Ограничений на число файлов в каталоге нет. Разные
каталоги («ветви» дерева каталогов) могут размещаться на разных дисках, это незаметно для
пользователя. Чтобы обратиться к файлу, не нужно знать о том, на каком физическом
устройстве или разделе диска записан файл. Это значит, лихорадочный поиск по дискам С:,
D: E:, K:, R:, Y: незнаком человеку, работающему с UNIX’ом. Он лихорадочно ищет
потерянные файлы в густой кроне UNIX-каталогов, начиная от корня.
Между прочим, забавно, что уже много лет все упорно называют деревом структуру
каталогов, у которой корень находится наверху, а его ближайшие отростки-подкаталоги
называются каталогами верхнего уровня… Кто из нас видел деревья, растущие кронами
вниз?

Поддерживаемые типы файловых систем

Основной («родной») файловой системой Solaris является UFS (Unix file system). Всего Solaris
9 поддерживает 13 файловых систем, перечисленных в Табл. 3.

файлова тип устройство описание

я
система

UFS обычная диск родная файловая система Solaris

VxFS обычная диск журналируемая система от Veritas Corp
QFS обычная диск файловая сисема от LSC Inc.
pcfs обычная диск MSDOS FAT и FAT32
hsfs обычная диск файловая система High Sierra (для CD-
ROM); она же – ISO9660
tmpfs обычная память использует оперативную память и
область свопинга

36
nfs псевдосисте сеть файловая система для монтирования
ма каталогов на других компьютерах
(подобно разделяемым каталогам
Windows)
cachefs псевдосисте другая ФС использует локальный диск для кэширования
ма удаленной файловой системы NFS
autofs псевдосисте другая ФС использует динамические объекты для
ма монтирования других файловых систем
specfs псевдосисте драйверы файловая система файлов устройств /dev
ма
procfs псевдосисте ядро /proc – отображеине процессов в
ма структуру ФС
sockfs псевдосисте сеть соединения типа «сокет»
ма
fifos псевдосисте файлы программные каналы (pipe API)
ма
Табл. 3 Файловые системы, поддерживаемые Solaris 9 и 10

В довольно старых версиях UNIX поддерживалась всего одна файловая система. С

увеличением разнообразия носителей возникла необходимость поддержки разнородных
файловых систем на носителях разной природы. Так в 1985 году компания Sun Microsystems
пришла к реализации концепции виртуальной файловой системы.

Виртуальная файловая система представляет собой абстрактную файловую систему, которая

позволяет операционной системе одинаковым образом обращаться к файловым системам
разных типов.

Важно: Системные вызовы, подобные fopen() и chmod(), а также команды

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

К 1985 году операционные системы фирмы Sun использовали Berkeley fast filesystem (FFS).
Эта файловая система базировалась на концепции индексных дескрипторов, которая
органично трансформировалась в концепцию виртуальных индексных дескрипторов в новой
файловой системе UFS, которая вобрала в себя структуру FFS и новые идеи организации
виртуальной файловой системы. Взаимодействие независимого от конкретного типа
файловой системы уровня виртуальной файловой системы и файловых систем строго
определенных типов иллюстрирует Рис. 7.

Файловая система UFS претерпела некоторые изменения с 1985 года. Так, начиная с выпуска
Solaris 9 8/03 поддерживаются многотерабайтные разделы, в то время как до этого UFS в
Solaris могла работать только с разделами размером до 1 Тб. В настоящее время большие
разделы поддерживаются только в 64-разрядной версии Solaris 9.

37
 Рис. 7 Структура виртуальной файловой системы Solaris

Файловые системы UFS, VxFS и QFS, поддерживаемые в Solaris, отличаются по некоторым

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

Выделение пространства блоками позволяет минимизировать фрагментацию файловой

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

Файловая система как выделяется есть ли журналирование

пространство под файл

UFS блоками (block) да

VxFS экстентами (extent) да
QFS экстентами (extent) нет
Табл. 4 Некоторые свойства файловых систем UFS, VxFS и QFS

В файловой системе UFS размер блока может составлять от 512 байт до 8192 байт, по
умолчанию в Solaris принят размер 8192 байт.

В Solaris поддерживается журналирование (logging) файловых систем UFS и VxFS.

Журналирование позволяет записывать в журнал информацию обо всех начатых транзакциях.
Если транзакция (т.е. операция записи на диск) по каким-то причинам не была завершена
(например, отключилось питание), то после перезапуска системы файловая система будет
автоматически возвращена в состояние, в котором она была до начала транзакции. Подобную
функциональность предоставляет файловая система ext3fs в Linux, reiserfs для FreeBSD и
Linux и некоторые другие.

38
В последние годы непременным условием использования файловой системы стала
поддержка современных дисков больших объемов и больших файлов. Если несколько лет
назад «большим» назывался диск объемом в 1 гигабайт, то сейчас дисковые массивы объемом
в несколько терабайт становятся обычными для систем среднего класса. Скоро они придут в
системы малых офисов и в дома, а сети предприятий начнут работать с серверами, в которых
установлены дисковые массивы, содержащие десятки и сотни терабайт информации. Что на
это отвечают создатели файловых систем для UNIX?

С 1991 года файловая система UFS претерпела заметные изменения, появилась версия UFS2.
В Solaris модификация файловой системы позволила достичь предела поддерживаемого
дискового объема одного раздела UFS в 1 терабайт.

дерево каталогов
Все файлы в UNIX организованы древовидно: всегда существует корневой каталог, который
обозначается “/”. В нем есть подкаталоги. Обычно есть подкаталоги, перечисленные в Табл.
5.

lrwxrwxrwx 1 root root 9 Янв 22 14:54 bin -> ./usr/bin

drwxr-xr-x 1 root root 16384 Янв 1 1970 boot
drwxr-xr-x 2 root root 512 Янв 29 14:42 cdrom
drwxr-xr-x 14 root sys 3584 Мар 16 15:49 dev
drwxr-xr-x 5 root sys 512 Янв 22 15:03 devices
drwxr-xr-x 51 root sys 3584 Мар 16 15:49 etc
drwxr-xr-x 3 root other 512 Янв 28 17:38 exports
drwxr-xr-x 3 root nobody 512 Янв 28 16:57 floppy
dr-xr-xr-x 1 root root 1 Мар 16 15:49 home
drwxr-xr-x 12 root sys 512 Янв 22 14:56 kernel
drwx------ 2 root root 8192 Янв 22 14:53 lost+found
drwxr-xr-x 2 root sys 512 Янв 22 14:54 mnt
drwxr-xr-x 3 root sys 512 Янв 22 15:48 opt
dr-xr-xr-x 63 root root 30912 Мар 16 15:52 proc
drwxr-xr-x 2 root sys 1024 Янв 22 15:51 sbin
drwxrwxrwt 6 root sys 368 Мар 16 15:50 tmp
drwxr-xr-x 34 root sys 1024 Янв 28 19:16 usr
drwxr-xr-x 32 root sys 512 Янв 22 15:57 var

Табл. 5 Обычные подкаталоги корневого каталога Solaris 9

Каталог /bin является символической ссылкой на каталог /usr/bin: так бывает не всегда.

Характерным свойством Solaris является выделение отдельного каталога /exports, в котором

сосредотачиваются разделяемые по сети подкаталоги, доступные для пользователей других
компьютеров. Каталог /opt, куда устанавливается некоторое дополнительное программное
обеспечение (от optional, необязательное) тоже есть системах Solaris, но отсутствует во
многих других системах UNIX.

Каталог для временных файлов /tmp монтируется в Solaris на отдельную виртуальную файловую систему типа
tmpfs. Это особый тип файловой системы. Если в системе есть свободная оперативная память, то драйвер tmpfs
хранит данные, записанные на файловую систему этого типа в оперативной памяти, а не диске. Если объем
свободной памяти падает и она начинает требоваться другим программам, файлы из tmpfs записываются на
раздел свопинга. Получается, что файлы, размещенные в файловой системе типа tmpfs всегда занимают остаток
оперативной памяти системы, чтобы она использовалась эффективно. Если свободной памяти нет, tmpfs

39
размещается в пространстве свопинга.

Это автоматически приводит к тому, что записанные в файловую систему tmpfs файлы теряются после
перезагрузки. Поэтому не следует записывать в /tmp какие-либо полезные файлы.

Скорость работы файловой системы tmpfs высока, т.к. часто все ее файлы физически расположены в
оперативной памяти. Вследствие этого кэширование файлов на tmpfs не производится: они и так хранятся не на
диске.

Казалось бы, использование tmpfs таит в себе резерв увеличения производительности любого приложения,
поскольку достаточно записать данные в каталог /tmp и работать с ними там, чтобы скорость доступа к данным
возросла многократно. На самом деле это не так, потому что чтение и запись любых дисков кэшируется, и лишь
для некоторых приложений использование tmpfs оправдано. Несомненно увеличивается быстродействие
компиляторов и других программ с большими объемами промежуточных файлов – но они и так используют
/tmp для хранения временной информации в процессе работы.

По умолчанию Solaris применяет tmpfs только для /tmp. При этом система избегает
существенного объема дискового ввода-вывода, так как /tmp используется для временных
файлов различных программ.

Внимание: создание отдельного раздела /tmp на диске приведет к тому, что /tmp не будет
создан системой автоматически с типом файловой системы tmpfs и производительность
системы может уменьшиться!

файлы и каталоги

типы файлов
Если дать команду ls –l, то тип файла будет указан первым символом первого столбца вывода:

#ls –l /etc

lrwxrwxrwx 1 root root 14 Янв 22 14:59 aliases -> ./mail/aliases

drwxr-xr-x 2 root bin 512 Янв 22 15:53 apache
...
-rw-r--r-- 1 root root 12 Янв 23 08:35 defaultrouter
-r--r--r-- 1 root root 1825 Янв 22 15:42 device.tab
-rw-r--r-- 1 root sys 2467 Янв 22 15:02 devlink.tab
drwxr-xr-x 2 root sys 512 Янв 22 14:54 dfs
prw------- 1 root root 0 Мар 16 15:50 initpipe
-rw-r--r-- 1 root sys 1087 Янв 23 08:33 inittab

Вывод команды ls для каталога /etc сильно обрезан в этом примере, там несравнимо больше
файлов. Нас интересуют различные типы файлов, которые мы здесь встретим.
В системах UNIX файлы могут быть обычными (этому типу соответствует обозначение -), а
также представлять собой каталог (d), файл символьного (c) или блочного (b) устройства,
символьную ссылку на другой файл (l), программный канал (p). В Solaris есть еще
специальный тип door (дверь), ассоциированный с набором потоков в системе и требуемый
для программирования взаимодействия потоков.

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

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

Каталог представляет собой файл специального формата, содержащий имена файлов,

которые лежат в этом каталоге, и номера их индексных дескрипторов. Подробнее об
индексных дескрипторах рассказано в разделе “индексные дескрипторы”.

Файлы символьных или блочных устройств – это файлы, которые располагаются в каталоге
/dev или связанном с ним, как рассказано в лекции 6. Обмен данными с символьным
устройством (например, с терминалом) идет посимвольно, с блочным (например, с диском) –
поблочно.

О символьных ссылках будет рассказано ниже в разделе «символьные ссылки»; это – файлы
специального типа, аналог ярлыка в Windows.

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

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

В таблице сведены все типы файлов в Solaris

d каталог (directory)
D дверь (door)
l символическая ссылка (symbolic link)
b файл блочного устройства (block)
с файл символьного устройства, устройства прямого доступа (character)
p специальный файл программного канала (FIFO, named pipe)
s сокет
- обычный файл

имена файлов и каталогов

На имена файлов и каталогов распространяются одинаковые ограничения. Так, длина имени
файла не должна превышать 255 символов, полное имя файла (т.е. путь от корня файловой
системы до файла) не должен быть длиннее 1023 символов.

Имена файлов и каталогов в UNIX состоят из латинских букв верхнего и нижнего регистра,
цифр и знаков препинания. Регистр букв имеет значение! Буквы верхнего и нижнего регистра
в UNIX считаются разными символами, имена Alliance и alliance – это разные имена, хотя и
отличаются всего одной буквой.

41
Из знаков препинания рекомендуется использовать только точку “.”, тире “-“ и
подчеркивание “_”. Использование других знаков (запятых, скобок, звездочки, решетки,
вопросительного и восклицательного знаков и других) теоретически возможно, но неудобно.
Дело в том, что командные процессоры и стандартные системные функции в UNIX
интерпретируют такие знаки специальным образом (а именно, как шаблоны имен файлов или
модификаторы команд в командном процессоре). Обращаться к файлу с именем ,/?*&^q-
+|! придется тоже специальным образом, а это быстро надоест.

В UNIX’e не используется понятие «расширение имени файла», так как точка считается
равноправным символом в имени. Следовательно, имя several.news.from.New.York смотрится
в UNIX не более экзотично, чем index.html. UNIX не делает предположений о содержимом
или назначении файла в зависимости от его имени и того, какие символы стоят справа от
самой правой точки в имени.

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

file bad.words
English text

Программа file использует специальный файл образцов /etc/magic. Он содержит сведения

о том, как должен выглядеть файл, чтобы его можно было отнести к какому-либо известному
типу: текст (text), текст программы на языке С (C program), исполняемый код (executable file),
данные (data) и т.д.

Имя может быть полным (абсолютным) или относительным. Полное имя файла – это имя с
указанием пути к файлу от корневого каталога, например,
/usr/local/squid/etc/squid.conf. Полное имя легко идентифицировать: оно всегда
начинается с символа “/”.

Относительное имя файла может быть очень коротким, например, просто f. Если в имени
файла вообще нет знака “/” (слэш), то имя относится к файлу текущего каталога. Если слэш
есть (но не в начале имени – например, squid/etc/squid.conf), то все, что находится
слева от первого в имени слэша, расценивается как подкаталог текущего каталога.

Полное имя любого файла не должно быть длиннее 1023 символов. Однако, для обращения к
файлу, расположенному очень глубоко в структуре каталогов, следует перейти в
промежуточный каталог командой cd и оттуда обратиться к файлу по относительному имени.
Скажем, вместо

vi /usr/home/ivan/projects/united_states/texas/cowboys/horses/\
red/seats/sellers_training

можно обратиться к тому же файлу так:

cd /usr/home/ivan/projects/united_states
vi texas/cowboys/horses/red/seats/sellers_training

Кстати, обратите внимание на ввод многострочных команд: при необходимости перейти на

следующую строку при вводе длинной команды следует использовать символ экранирования
(обратный слэш) “\”. Следующий за ним символ перевода строки в таком случае будет

42
интерпретирован как пустой символ, а не как символ завершения команды.

Полное имя файла также называют «путем к файлу» , «путем файла» или «путевым именем
файла».

Символ “~” (тильда) в большинстве командных интерпретаторов обозначает домашний

каталог пользователя. Например, команда
cd ~anna/
требует перейти в домашний каталог пользователя anna, а знак «~» без имени пользователя
означает домашний каталог текущего пользователя. Впрочем, интерпретатор sh знак ~ так не
воспринимает, пользуйтесь bash!

действия с файлами и каталогами

Обычный (regular) файл может содержать текст или двоичные данные.
Создать текстовый файл можно в любом текстовом редакторе или перенаправив вывод какой-
либо программы в файл. Часто для создания какого-нибудь тестового короткого файла так и
делают. Например, после установки веб-сервера можно проверить, корректно ли он
откликается на внешний запрос, только если у нас уже есть файл index.html, который он
должен выдать в ответ на запрос. Быстрее всего создать этот файл так:
#cat > index.html
<HTML>
<BODY>
Hello everybody!
</BODY>
</HTML>
^D
#
Пустой файл можно создать командой touch, которая изначально была придумана для
изменения времени модификации файла на текущее системное время:

touch filename

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

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

mkfile 500m testfile

создаст файл testfile размером 500 мегабайт. Команда mkfile специфична для Solaris (хотя
в ряде дистрибутивов Linux и FreeBSD она тоже может быть).

Файлы копируют командой cp:

cp file1 file2
Переименование файла выполняет команда mv:
mv file1 file2
Командой mv файл можно переместить в другой каталог:

43
mv file /usr/progs/useless/
Если Вы переносите или копируете файл или несколько файлов в каталог, то имя каталога
правильнее указывать с завершающим слэшем в конце имени (например,
/usr/progs/useless/). Это явным образом указывает на то, что имеется в виду именно
каталог.
Если произошла ошибка и последний аргумент команды оказался не каталогом, а файлом,
программа сообщит об этом. Если слэш не указать, то в случае ошибки старое содержимое
файла, в который копируется новая информация, будет безвозвратно утеряно.
Файлы удаляют с помощью команды rm. В системах UNIX не предусмотрена возможность
восстановления удаленных файлов (unerase), поэтому все, что стерто, пропадает навсегда.
Системы UNIX в структуре файловой системы не имеют «мусорной корзины» (trash), в
которую файлы попадают перед окончательным удалением. Однако, большинство
графических сред обеспечивают такую «корзину», но только для тех файлов, которые были
удалены программами, специально написанными с учетом этой возможности среды. Так, в
Solaris в CDE есть своя корзина. В нее попадают те удаленные файлы и каталоги, которые
были удалены программами, знающими об этой корзине. Как правило, о ее существовании
подозревает только File Manager CDE. Возможность восстановления стертых файлов
предоставляется не операционной системой, а графической оболочкой CDE, поэтому не стоит
рассчитывать, что любой файл можно восстановить из корзины CDE. Например, если файл
был удален командой rm из командной строки xterm (эмулятор терминала для графической
среды), то его уже не восстановить. Команда rm не знает о существовании корзины в CDE,
даже если запускается в окне терминала в графическом режиме.

Вывести файл на экран можно командами cat, more, less, pg, page.

Программы cat и more есть в любой системе UNIX, другие перечисленные выше команды
- это варианты команды more и присутствуют не всегда. Назначение more и ее коллег –
поэкранный вывод длинных файлов. При выводе информации программа more
останавливается, заполнив экран содержимым очередной страницы файла и ждет команды.
По нажатию «Enter» выводится следующая строка, по нажатию «пробела» – следующая
страница. Можно искать подстроку в тексте, по команде
/подстрока
Клавишами <Ctrl-B>, <Ctrl-F> можно перемещаться назад и вперед на одну страницу,
клавиша q служит для выхода из программы во время просмотра текста.

Каталоги
Слово «каталог» - употребляется наряду со словом «директория» (directory). В терминологии
большинства Windows-систем то же самое обозначает слово «папка» (folder). Среди
системных администраторов UNIX принято употреблять термин «каталог».
Каталог представляет собой файл особого типа, который содержит таблицу из двух столбцов:
в первом из значится имя файла, во втором – номер индексного дескриптора, который
описывает файл. В одном каталоге не может быть файлов или подкаталогов с одинаковыми
именами.

Каталог может содержать и файлы, и подкаталоги. Пустой каталог создается командой

mkdir. Удалить пустой каталог можно командой rmdir, непустой каталог удаляется
командой

rm –rf каталог

44
например, по команде

rm –rf /usr/local/squid/

будут удалены каталог /usr/local/squid, а также все файлы в нем и все его подкаталоги.

Перенести или переименовать каталог можно командой mv, для копирования каталогов
вместе с подкаталогами используется команда cp –Rp.

Список файлов и подкаталогов в каталоге выдает команда ls. Если запустить ls без
параметров, она выдаст только список имен фaйлов. Эта команда имеет множество ключей,
из которых более всего полезны перечисленные в Табл. 6

l (long) вывести полную информацию о файле

a (all) вывести все файлы, в том числе те, чьи имена начинаются с
точки
i (i-nodes)вывести номера индексных дескрипторов
t (time) отсортировать файлы по времени последней модификации
Табл. 6 Некоторые ключи программы ls

В каждом каталоге при создании всеглда появляются две записи – “.” (точка) и “..” (две
точки). “Точка” ссылается на сам текущий каталог, а “две точки” – на родительский каталог. В
корневом каталоге обе эти записи указывают на корневой каталог.

По умолчанию программа ls выводит информацию обо всех файлах, за исключением тех,

чьи имена начинаются с символа «.» (точка). При указании ключа -a эти файлы тоже
включаются в общий список.

Файлам, которые содержат важную конфигурационную или служебную информацию

традиционно дают имена, начинающиеся с символа «точка». Таковы, например, файлы
.profile, .xsession, .bashrc, .history и другие.

Перейти из одного каталога в другой можно по команде

cd каталог
Комадна cd без аргументов вызывает переход в домашний каталог текущего пользователя и
эквивалентна cd ~.

Вывод на экран полного имени текущего каталога выполняется командой pwd.

ссылки
В любой системе UNIX существуют жесткие и символические ссылки.

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

45
# ls -li file*
16852 -rw-r--r-- 2 root root 0 Mar 20 16:11 file
16852 -rw-r--r-- 2 root root 0 Mar 20 16:11 file1

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

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

Жесткие ссылки создает команда ln:

ln старо е _ имя н о в о е _ имя

При создании жесткой ссылки сам файл не модифицируется, старое имя никак не изменяется,
результат выполнения команды проявляется только в создании еще одного имени этого
файла.

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

Файл в любой файловой системе UNIX считается удаленным только тогда, когда удалены все
жесткие ссылки на него. Удаление жесткой ссылки выполняется командой rm и внешне
ничем не отличается от удаления обычного файла.

Найти все жесткие ссылки на файл можно с помощью команды find:

find отк уд а _ и с кать –inode н ом ер _ инд е к с н о г о _ д е с к р иптора _фай л а

Символическая ссылка – это запись в каталоге, ссылающаяся на файл с определенным

именем. Фактически, символическая ссылка – это отдельный файл типа «символическая
ссылка», и индексный дескриптор этого файла содержит только путь к файлу или каталогу, на
который указывает ссылка:

ls –l
lrwxrwxrwx 1 root root …. qq ->/usr/home/qq

Можно создать символическую ссылку на любой каталог, а также на файл, находящийся в

другом разделе UNIX. Символическая ссылка является аналогом ярлыка (shortcut) в системах

46
Windows. При удалении символической ссылки с файлом ли каталогом, на который она
ссылается, ничего не происходит. При удалении файла, на который ссылкается
символическая ссылка, она «повисает в воздухе», ссылаясь на пустоту. В последнем случае
при обращении к такой «пустой» ссылке возникнет ошибка file not found, несмотря на
то, что сама ссылка будет видна и доступна в списке файлов.

Обычно по команде ls –l выдается не только информация о типе файла l, если это

символическая ссылка, но и указывается, на она что ссылается. Если эта информация не
появилась, попробуйте ls –F. В разных системах UNIX ключи программы ls могут
незначительно отличаться.

права доступа

Давно известно, что в Москве раньше были две угнетаемые нации: "погазоны" и "улюки". Их
никто никогда не видел, но всем было их очень жалко. Куда ни пойдешь, везде пестрели
надписи: "Погазонам не ходить", "Машины улюков не ставить".

В каждой многопользовательской системе полагается развешивать такие таблички по каталогам, чтобы доступ
к информации имели только те, кому он разрешен.
Система безопасности UNIX основывана на правах доступа к объектам файловой системы – файлам и
каталогам. У каждого каталога или файла есть один владелец и один групповой владелец. Группового
владельца файла мы будем для краткости называть группой файла.
Читая словосочетание «группа файла» не следует считать, что файлы объединены в каки-то группы. Группа
файла обозначает группу пользователей, которой даны некие специальные права на доступ к этому файлу.

Дав команду ls –l в любом каталоге, мы увидим нечто вроде

-rw-r--r-- 1 root root 433 Feb 2 10:30 acd.c

Первый столбец – это тип файла (первый символ) и права доступа (остальные девять
символов). Затем указаны число жестких ссылок на файл, владелец и группа файла, размер
файла в байтах, дата последней модификации в формате «Месяц Число Год» и имя файла. Год
часто не указывается для тех файлов, которые были модифицированы в течение последних 12
месяцев.

Права доступа делятся на три части: права, данные, соответственно, владельцу файла, группе
файла и всем остальным (обозначаются термином other или world). Таким образом, девять
бит слова прав доступа делятся на три части по три бита:
rwx | rw- | r--|
u g o

Часть, обозначенная буквой u (user), определяет права доступа владельца файла, буквой g –
права доступа группы файла, o – права всех остальных. Существуют права трех типов: на
чтение (r, read), запись (w, write) и запуск на выполнение (x, execute). Пользователю, который
хочет обратиться к файлу, даются права доступа либо владельца, либо группы файла, либо
права “всех остальных”. Права доступа проверяются так (см.Рис. 8, на примере слова прав
доступа rwxrw-r--):

47
Рис. 8 Алгоритм получения доступа к файлу

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

система выясняет, является ли он владельцем файла. Если является, то он получает права
доступа, определенные для владельца файла. Если он – не владелец, но входит в группу,
которая является группой файла, то он получает права доступа, определенные для группы
файла. Если он не относится ни к одной из этих двух категорий, он получает права,
определенные для всех остальных. Права разных категорий пользователей не складываются:
если доступ к файлу хочет получить его владелец, и он входит в группу файла, но права
группы более широкие, чем права владельца (например, слово прав доступа r-xrwxr--), то он
все равно получит права владельца (в последнем примере – r-x). Для большинства файлов и
каталогов права их владельца обычно шире, чем у группы.

Слово прав доступа представляет собой последовательность из двенадцати бит. Для

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

мнемоническое обозначение слова прав доступа: rwxrw-r—

двоичное представление слова прав доступа 111 110 100
десятичное представление слова прав доступа: 7 6 4

В документации часто встречается требование при установкекакой-либо программы

установить права доступа для некоего каталога 755. Имеются в виду, понятно, права rwxr-xr-
x, что соответствует полному доступу владельцу и доступу на чтение и запуск группе и всем
остальным.

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

Старшие три бита слова прав доступа относятся к запуску файла, поэтому детально они

48
рассмотрены в лекции 8. Вот как выглядит слово прав доступа:

su sg t r w x r w x r w x

Старшие три бита – это бит установки владельца при запуске файла (suid), бит установки
группы (sgid) при запуске файла и бит запрета выгрузки файла на диск при выполнении (t).

Для каталога биты suid и sgid имеют другое значение. По умолчанию при создании файла он
наследует владельца и группу от процесса, который его создал. Аналогичное правило
действует и на каталоги. Однако, в правах доступа к каталогу установлен бит suid, то
созданный в нем файл или подкаталог будет принадлежать не владельцу по умолчанию, а
владельцу каталога с битом suid. Это правило не работает для систем Solaris, хотя
справедливо для некоторых других систем UNIX.

В Solaris это правило распространяется только на группу файла, но не на владельца. То есть

владельцем нового файла будет владелец создавшего его процесса, независимо от наличия
бита suid у каталога, где создан файл. Но если каталог имеет установленный бит sgid, то
группой нового файла станет группа процесса-создателя.

Бит запрета выгрузки файла на диск при выполнении (sticky bit) в старых версиях UNIX
использовался для указания того, что при выполнении программы, записанной в этом файле,
ее страницы запрещено выгружать на диск. В настоящее время sticky bit используется для
каталогов, с тем, чтобы указать особые условия удаления файлов из каталога. Если sticky bit
установлен для каталога, то все пользователи, кроме root’a, могут удалять из каталога только
те файлы, которые им принадлежат, независимо от прав доступа к каталогу. В разных
системах UNIX он может интерпретироваться по-разному, поэтому смотрите для уточнений
man sticky и man chmod.

индексные дескрипторы
Формат таблицы индексных дескрипторов и самих дескрипторов обсуждался в лекции 6.
Следует сказать, что непосредственное изменение индексного дескриптора невозможно, так
как модификацию дескриптора выполняют различные программы в процессе своей работы.
Нет необходимости вмешиваться в содержимое индексного дескриптора напрямую. Для
восстановления таблицы индексных дескрипторов после сбоя следует воспользоваться
программой fsck.

списки ACL

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

chgrp нужная_группа файл

chmod g=rw файл

А если надо дать право доступа только одному из членов этой группы? Тогда можно создать

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

addgroup новая_группа
chgrp новая_группа файл
chmod g=rw файл
#редактируем /etc/group и добавляем в новую группу существующего пользователя
vi /etc/group

Такое ухищрение нам помогло, но что делать, если надо дать право чтения, записи и запуска
двум разным пользователям, а еще двум – право чтения и записи, а еще одному – только
чтения. а всем остальным – вообще не дать доступ к этому файлу? На такой вопрос нет
ответа, если вы работаете в «классической» версии UNIX. Однако, некоторые современные
системы UNIX (например, Solaris и FreeBSD) обладают требуемым механизмом. Это – списки
управления доступом к файловой системе, access control lists (ACLs).

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

Здесь и далее мы будем называть ACL для файлов и каталогов «расширенными правами
доступа». Расширенные права доступа к файлам и каталогам устанавливаются командой
setfacl.

Они представляют собой ряд полей, разделенных двоеточиями:

entry_type:[uid|gid]:perms

Здесь entry_type – тип расширенного права доступа, uid и gid – идентификаторы пользователи
и группы, соответственно, а perms – собственно назначаемые права доступа.

Расширенные права доступа (ACL) к файлам

Расширенные права доступа к файлу могут быть такими, как показано в Табл. 7.

u[ser]::perms права доступа хозяина файла.

g[roup]::perms права доступа группы файла
o[ther]:perms права всех остальных
m[ask]:perms маска ACL
u[ser]:uid:perms права доступа указанного пользователя; в
качестве uid можно указать и UID, и имя
пользователя
g[roup]:gid:perms права доступа указанной группы; в
качестве gid можно указать и GID, и имя
группы

Табл. 7. Расширенные права доступа к файлам

Маска задает максимальные права доступа для всех пользователей, за исключением хозяина

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

Расширенные права доступа (ACL) к каталогам

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

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

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

d[efault]:u[ser]::perms права хозяина файла по

d[efault]:g[roup]::perms
d[efault]:o[ther]:perms
d[efault]:m[ask]:perms
d[efault]:u[ser]:uid:perms
d[efault]:g[roup]:gid:perms
умолчанию
права группы файла по
умолчанию
права остальных
пользователей по
умолчанию
маска ACL по умолчанию
права доступа по
умолчанию для указанного
пользователя; в качестве uid
можно указать и UID, и имя
пользователя
права доступа по
умолчанию для указанной
группы; в качестве gid
можно указать и GID, и имя
группы

Табл. 8. Расширенные права доступа к каталогам

Присвоение расширенных прав доступа осуществляется программой setfacl с ключом –s

(set). Без этого ключа расширенные права доступа модифицируются, с ним –
устанавливаются в точности такими, как указано в данной команде setfacl.

Например, для установки права на чтение и запись файла project07 для пользователей lena и
petr надлежит выполнить команду

setfacl –m user:lena:rw-,user:petr:rw- project07

Ключ -m служит для добавления прав доступа, а не для их замены. Эффективные (т.е. те,
которые в самом деле будут иметь место) права доступа пользователей lena и petr определяют

51
не только их персональные права доступа к этому файлу, но и маска, которая показывает
права доступа по умолчанию. Из персональных прав и маски выбираются наиболее строгие
ограничения, поэтому, если в персональных правах доступа или в маске для файла project07
отсутствует право на запись, ни lena, ни petr не получат реальной возможности изменить
файл project07.

Расширенные права доступа не показываются в выводе программы ls, но команда ls –l

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

getfacl имя_файла

Более подробную информацию о ключах setfacl и getfacl следует получить из man.

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

Монтирование файлов в качестве устройств (lofi)

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

Для работы с образом диска, записанным в файл, требуется программа lofiadm, которая
управляет драйвером lofi. Этот драйвер позволяет связать файл с блочным
псевдоустройством. После этого содержимое файла будет доступно посредством обращения
к файлу этого блочного устройства. У системы будет полное впечатление, что это и есть
устройство и его можно монтировать с помощью mount, проверять на корректность записей
на нем с помощью fsck и т.п.

Программу lofiadm следует использовать для добавления таких псевдоустройств, удаления

связи файла и псевдоустройства и выводе информации о таких устройствах в системе.
Например, можно смонтировать образ компакт-диска стандарта ISO, лежащего в файле ex.iso:

lofiadm -a /home/ivan/ex.iso /dev/lofi/1

Затем можно смонтировать новое устройство в системе:

mount -F hsfs -o ro /dev/lofi/1 /mnt

и проверить, видно ли его:

df -k /mnt

Filesystem
kbytes used avail capacity Mounted on
/dev/lofi/1
512418 512418 0 100% /mnt

52
Для демонтирования псевдоустройства и его удаления из системы следует дать следующие
команды:
umount /mnt
lofiadm -d /dev/lofi/1

Обратите внимание на возможность создания файловой системы на псевдоустройстве и

появление устройства прямого доступа (rlofi, аналогично rdsk) после выполнения lofiadm –a:

lofiadm -a /export/home/test
/dev/lofi/1
newfs /dev/rlofi/1
newfs: construct a new file system /dev/rlofi/1: (y/n)? y

/dev/rlofi/1:
71638 sectors in 119 cylinders of 1 tracks, 602 sectors 35.0MB in 8 cyl
groups (16 c/g, 4.70MB/g, 2240 i/g) super-block backups (for fsck -F ufs -o b=#)
at: 32, 9664, 19296, 28928, ...

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

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

После перезагрузки связь файла и псевдоустройства теряется, если требуется сделать ее

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

Возможность управлять псевдоустройствами зависит от прав доступа к файлу /dev/lofictl. По

умолчанию правом монтирования и демонирования псевдоустройств обладает только root.

Устройство и администрирование файловой системы UFS

разбиение диска на разделы

Разбиение диска на разделы производится в двух случаях: при установке системы и при
подключении нового диска. Разбиение на разделы следует спланировать так, чтобы в
будущем размеры разделов были достаточны для установки программ и размещения файлов
данных. В Solaris должны быть созданы как минимум два раздела: корневой (root) раздел,
монтируемый в файловой системе в корень ее дерева и обозначаемый символом «/» (слэш), и
раздел для свопинга. Последний не имеет точки монтирования, так как не принадлежит к
файловой системе и не размечается, а используется для прямых чтения страниц с диска и
записи страниц на диск.
Для более надежной и быстрой работы системы принято, кроме упомянутых разделов,
создавать разделы с точками монтирования /usr, /export/home и, возможно /opt. Далее мы
будем называть разделы по именам точек монтирования (например, раздел /usr).

Отметим, что при использовании файловой системы ZFS думать о разбиении диска на
разделы незачем, но об этом подробнее рассказывается в лекции 8.

В корневом каталоге системы располагается несколько файлов и ряд обязательных для

53
работы системы подкаталогов. Это подкаталоги /bin, /sbin, /dev, /devices, /etc, /tmp. Также
обычно есть подкаталоги /usr и /opt, а также /export, они обычно являются точками
монтирования других разделов.

Корневой каталог в типичной установке Solaris (набор программ Entire Distribution –

подробнее см. главы 3 и 4) занимает 200 Мб (при условии, что каталоги /usr, /var и
/export/home размещены в других разделах). При установке системы ему следует выделить
300 Мб – с запасом. Каталог /usr займет не меньше 1400 Мб, /var – не менее 100 Мб. Для
каталога /var имеет смысл выделить больше места, т.к. именно в нем будут содержаться
быстро растущие в размере файлы протоколов, почтовые ящики пользователей и прочее.
Приведенные объемы разделов справедливы для варианта установки с набором программ
Entire Distribution.

Вообще говоря, перед планированием разделов следует подумать о том, как будет
использоваться компьютер под управлением Solaris. Если это будет сервер Oracle, надо
зарезервировать один неразмеченный (неотформатированный) раздел под базы данных
Oracle. Если планируется сделать почтовый сервер, то следует отвести под раздел /var
достаточно места для размещения всех почтовых ящиков в каталоге /var/mail, а если это
будет файловый сервер, надо сделать отдельный большой раздел для хранения файлов
пользователей (например, /export/home).

Таким образом, фактическое пространство, которое следует отвести под каталог /var,
зависит от назначения компьютера. Исходя из собственного опыта, я всегда создаю для /var
раздел размером как минимум 256Мб в системах с небольшой нагрузкой (почтовый сервер,
http-cache и ftp для сети из 10-50 компьютеров) и до 2-3Гб в системах со средней нагрузкой
(почтовый сервер, http-cache, СУБД типа MySQL, веб-сервер с 5-10 виртуальными хостами в
сети из 50-150 компьютеров).

При установке системы программа-установщик предложит вам разумные значения по

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

При установке нового диска его разметку поможет провести программа format. Эта
программа также может использоваться для получения информации о геометрии диска, для
низкоуровнего форматирования SCSI-дисков и восстановления некоторой служебонй
информации после сбоев.

разметка нового диска

Предположим, мы подключили новый диск, и это IDE primary slave диск. Для того, чтобы
создать на нем файловую систему, потребуется создать на новом диске разделы (по крайней
мере один) и затем на каждом из разделов создать новую файловую систему.

Создание разделов на диске выполняется с помощью команды format или fdisk. Последняя
применяется только для платформы x86. Однако, из format можно вызвать fdisk и делать
именно так предпочтительнее. Почему – будет ясно из следующего описания.

54
После подключения нового диска нет надобности перенастраивать ядро Solaris, если диски
этого типа в системе уже есть. Например, если у вас уже есть один IDE-диск, и система с ним
уже работает, незачем перезапускать систему с ключом r или создавать файл /reconfigure и
перезапускаться для обнаружения нового устройства. Достаточно создать новые файлы
устройств в каталогах /devices и /dev. Для этого в более ранних версиях Solaris использовалась
программа disks, а начиная с версии Solaris 9 следует запускать devfsadm. При запуске без
параметров новый диск будет обнаружен и требуемые файлы будут молча добавлены в
каталоги /devices, ./dev/dsk и /dev/rdsk.

Теперь любая программа работы с диском, требующая файл устройства в каталоге /dev/rdsk,
уже может работать с диском. Запустим программу format. В меню программы следует
выбрать диск, а затем выбрать запуск fdisk. После этого мы будем работать в среде
программы fdisk. Ее интерфейс нам знаком по другим системам, только обратите внимание,
что есть возможность создавать разделы нескольких типов. Если мы добавляем
дополнительный диск для работы с ним из среды Solaris, то следует выбрать тип Solaris.
Раздел на новом диске не должен быть помечен как «активный», если только с него не будет
загружаться какая-нибудь система в будущем.

Можно запустить программу fdisk самостоятельно, без предварительного вызова программы

format, но последняя все равно будет нужна на следующем этапе.

После создания раздела следует выйти из fdisk, и в программе format выбрать

partition->print.
Если определен размер только одного подраздела (partition), а именно – подраздела номер 2,
это говорит о том, что для созданного раздела fdisk следует определить подразделы. Если это
отвечает вашим намерениям, достаточно создать всего один подраздел размером с весь
раздел fdisk. то можно сделать через меню Partition программы format. Выбрав partition-
>номер подраздела (например, 0), будет легко задать его размер.

Обязательно выберите пункт label для записи получившейся таблицы разделов на диск.

После этого создадим новую файловую систему на получившемся подразделе. Помните:

разделы fdisk для Solaris – это лишь место для размещения подразделов типа solaris (slices).
А на этих подразделы как раз и существует файловая система UFS, и располагаются файлы и
каталоги. Файловую систему на новом диске создадим командой newfs.

Программа mkfs позволяет создавать файловые системы разных типов, включая UFS, а newfs
является более удобным интерфейсом к mkfs исключительно для создания файловых систем
UFS.

# newfs /dev/rdsk/c0d1s0

newfs: construct a new file system /dev/rdsk/c0d1s0: (y/n)? y

/dev/rdsk/c0d1s0: 2060352 sectors in 2044 cylinders of 16 tracks, 63
sectors
1006,0MB in 128 cyl groups (16 c/g, 7,88MB/g, 3776 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 16224, 32416, 48608, 64800, 80992, 97184, 113376, 129568, 145760, 161952,
178144, 194336, 210528, 226720, 242912, 258080, 274272, 290464, 306656, 322848,
339040, 355232, 371424, 387616, 403808, 420000, 436192, 452384, 468576, 484768,
500960, 516128, 532320, 548512, 564704, 580896, 597088, 613280, 629472, 645664,

55
661856, 678048, 694240, 710432, 726624, 742816, 759008, 774176, 790368, 806560,
822752, 838944, 855136, 871328, 887520, 903712, 919904, 936096, 952288, 968480,
984672, 1000864, 1017056, 1032224, 1048416, 1064608, 1080800, 1096992, 1113184,
1129376, 1145568, 1161760, 1177952, 1194144, 1210336, 1226528, 1242720, 1258912,
1275104, 1290272, 1306464, 1322656, 1338848, 1355040, 1371232, 1387424, 1403616,
1419808, 1436000, 1452192, 1468384, 1484576, 1500768, 1516960, 1533152, 1548320,
1564512, 1580704, 1596896, 1613088, 1629280, 1645472, 1661664, 1677856, 1694048,
1710240, 1726432, 1742624, 1758816, 1775008, 1791200, 1806368, 1822560, 1838752,
1854944, 1871136, 1887328, 1903520, 1919712, 1935904, 1952096, 1968288, 1984480,
2000672, 2016864, 2033056, 2049248,

Смонтируем получившуюся файловую систему в каталог /test:

# mount -F ufs /dev/dsk/c0d1s0 /test

# ls test
lost+found

Обратите внимание, при создании файловой системы сразу создается каталог lost+found
на ней, для того, чтобы при автоматическом восстановлении файлов после сбоя (при
перезагрузке, например) программе fsck было куда записать потерявшиеся фрагменты
файлов. Кроме этого, в некоторые блоки (их список выводится при работе newfs или mkfs)
записана резервная копия суперблока новой файловой системы.

количество индексных дескрипторов в файловой системе

Количество индексных дескрипторов в создаваемой файловой системе типа UFS можно
задать посредством указания параметра с ключом -i:

newfs –i nbpi raw_deivce_name

Например

newfs –i 2048 /dev/rdsk/c0d0p0

Параметр nbpi обозначает число байтов, приходящихся на один индексный дескриптор4, что
при известном объеме диска однозначно определяет число индексных дескрипторов в
файловой системе.

Программы mkfs и newfs поддерживают еще ряд ключей, которые позволяют гибко
описывать параметры создаваемой файловой системы.

элементы файловой системы

Файловая система каждого из разделов диска состоит из нескольких структурных элементов.
Это суперблок, таблица индексных дескрипторов, блоки описания файлов, блоки,
содержащие списки управления доступом к файлам (ACL – access control lists), каталоги и
собственно файлы.

Файловая система UFS содержит четыре основных компонента с управляющей информацией:

загрузочный блок, суперблок, таблицу индексных дескрипторов (i-node table) и каталоги.
Кроме этого, в Solaris (начиная с версии 2.55, с 1995 года) в файловой системе хранятся
4 имеется в виду число байт данных в файлах этого раздела, а не длина индексного дескриптора, последняя
фиксирована и равна 128 байтам – прим. авт.
5 Фактически, впервые Sun Microsystems ввела поддержку ACL для файловой системы UFS в 1993 году в

56
списки управления доступом (ACL). Хранение списков ACL обеспечивают так называемые
теневые индексные дескрипторы (shadow inodes).

В System V каждый раздел жесткого диска форматируется (размечается) для размещения на

нем файловой системы UNIX, в BSD – один раздел жесткого диска разбивается на
подразделы, каждый из которых форматируется. Мы называем “разделом UNIX” такой
размеченный в формате файловой системы UNIX раздел или подраздел.

Загрузочный блок (boot block) – это, как правило, часть метки диска (disk label). В
загрузочном блоке записана маленькая программа, которая при старте системы загружает
ядро ОС с диска в оперативную память. Загрузочный блок располагается в первом секторе
диска. Загрузочный блок имеет смысл только для первого раздела жесткого диска, однако
место для него резервируется в каждом разделе.
Суперблок содержит общую информацию о файловой системе как совокупности файлов на
данном разделе жесткого диска, в частности, размер раздела UNIX, число свободных и
занятых блоков и индексных дескрипторов и флаг целостности файловой системы. Этот флаг
устанавливается при успешном завершении работы с файловой системой, например, при
корректной остановке операционной системы. В случае, если компьютер выключили
рубильником, не дождавшись корректной остановки системы, при следующем старте
системы программа fsck автоматически начнет проверку дисков и выдаст сообщение “clean
flag is not set in superblock”. Копии суперблока многократно записываются в нескольких
блоках внутри каждого раздела для пущей надежности. В файловой системе UFS
записывается по одной копии суперблока на каждую группу цилиндров. Если выяснится, что
оригинал суперблока в начале раздела поврежден, будет использована копия суперблока.
Таблица индексных дескрипторов (i-node table) содержит дескрипторы файлов. Дескриптор
файла содержит сведения о типе файла, размещении файла на диске, правах доступа к нему,
UID владельца файла, GID группы файла, время последнего доступа к файлу, время
последней модификации файла, время последней модификации самого индексного
дескриптора. Подробнее структура таблицы индексных дескрипторов рассмотрена в
подраздел «таблица индексных дескрипторов: детали».

Размер индексного дескриптора фиксирован и составляет в Solaris в UFS 128 байт.

Размер таблицы индексных дескрипторов фиксирован и задается при создании файловой

системы на разделе. Программе mkfs (и, соответственно, newfs) можно явно указать
требуемое количество байт данных, которые должны приходиться на один индексный
дескриптор, что определит количество индексных дескрипторов на разделе. Например, если
раздел состоит из 1000000 байт, и число байт на дескриптор составляет 1000, то будет создано
1000 индексных дескрипторов.

таблица индексных дескрипторов: детали

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

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

специальной версии Solaris – Trusted Solaris, которая была сертифицирована на уровень безопасности B1.

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

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

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

Каждому файлу соответствует индексный дескриптор. Он хранит информацию о различных

атрибутах файла и его размещении на диске. В индексном дескрипторе записаны:
· тип файла
· права доступа к файлу
· идентификатор владельца файла
· идентификатор группы файла
· время последней модификации файла
· время последнего доступа к файлу
· время последней модификации самого индексного дескриптора
· число повторных использований индексного дескриптора (т.е. случаев, когда файл был
стерт и его индексный дескриптор был использован для хранения данных о другом файле)
· длину файла в байтах (для файлов устройств это поле имеет смысл сочетания major и
minor номера устройства, см. раздел «файлы устройств»)
· идентификатор файловой системы, в которой расположен файл;
· количество связей файла
· число блоков файла (требуется для поддержки работы с файлами, содержащими большие
области, заполненные символами с кодом “ноль”, т.е. пустое пространство; такие файлы
называются holey files – файлы с пустотами)
· номер теневого индексного дескриптора (если требуется)
· структура из 15 номеров блоков, описывающая размещение файла на диске; каждый
номер блока занимает 4 байта.

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

последовательность из номеров блоков.

Если файл имеет размер более двенадцати блоков (т.е. его длина больше 12*8192 =98304
байт), то предпоследние три номера обозначают не номера блоков данных, а номера
косвенных блоков (indirect blocks), в которых хранятся указатели на следующие блоки данных
и, возможно, на следующие косвенные блоки.

Первые двенадцать номеров блоков содержат просто номера блоков данных. Тринадцатый номер – это номер
косвенного блока первого уровня. В блоке первого уровня содержится до 2048 адресов блоков данных (речь
идет о 8192-байтных блоках).
Четырнадцатый номер блока содержит номер косвенного блока второго уровня. Косвенный блок второго уровня
содержит 2048 номеров косвенных блоков первого уровня, таким образом, через косвенный блок второго
уровня адресуется до 20482 блоков данных.
В пятнадцатый номер блока записан номер косвенного блока третьего уровня. Косвенный блок третьего уровня
содержит 2048 номеров косвенных блоков второго уровня, так что через косвенный блок третьего уровня
адресуется до 20483 блоков данных.

58
Файл не может располагаться на разных разделах UNIX. Файл может быть фрагментирован,
хотя файловая система построена так, чтобы свести фрагментацию к минимуму.
Теоретически рекомендуется не заполнять файловую систему более, чем на 70%, чтобы не
увеличивать фрагментацию при работе.

Максимальный размер файла может быть легко посчитан, так как мы знаем правила
адресации блоков данных. Если размер блока равен 512 байт, то
Напрямую адресуемые из индексного дескриптора блоки в сумме дают размер 12 × 8192
байт= 98304 байт
Адресуемые через номер косвенного блока первого уровня - 2048 × 8192 байт = 16777216
байт
Адресуемые через номер косвенного блока второго уровня – 20482 × 8192 байт = 34359738368
байт
Адресуемые через номер косвенного блока третьего уровня – 20483 × 8192 байт =
70368744177664 байта

Вместе получается примерно 64 Тбайта. Однако, Solaris 9, насколько об этом можно судить
по доступным фактам, не поддерживает файлы размером более 1 Тбайта на данный момент.

Все современные системы UNIX используют 128-байтный индексный дескриптор, который

вмещает больше информации и номер блока в нем занимает не 3 байта (как в прошлом), а 4.
Поэтому адресовать можно весьма большие разделы.

28 байт в таком дескрипторе отводится под разные расширения, включая место для 32-
разрядных идентификаторов владельца и группы файла, а также под 64-разрядные поля
времен модификации. Введение 64-разрядных полей времени в UNIX вместо прежних 32-
разрядных нужно для того. чтобы избежать «проблемы 2031 года», т.к. именно в этом году
перестанет хватать 32 байт для представления времени в системах UNIX. Разработчики
обоснованно полагают, что до тех пор все существующие системы UNIX будут
заблаговременно переведены на 64-разрядную архитектуру.

обычные индексные дескрипторы

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

теневые индексные дескрипторы

Теневые индексные дескрипторы (shadow i-nodes) содержат информацию, позволяющую
получать доступ к расширенным правам доступа (ACL) файла или каталога. Этот тип
файловых дескрипторов существует в реализации файловой системы UFS в Solaris, начиная с
версии 2.5.1. Solaris поддерживает теневые индексные дескрипторы для файловых систем
UFS (Unix File System), NFS (Network File System версий 2 и 3), CacheFS (Cache File System).
Информация о расширенных правах доступа в ZFS хранится иначе в силу более сложной
структуры служебных данных ZFS. Расширенные права доступа могут быть назначены в
отношении каталогов, обычных файлов, символических ссылок и именованных каналов
(FIFO).

59
Если в отношении файла назначены расширенные права доступа (например, с помощью
команды setfacl), то будет создан теневой индексный дескриптор для этого файла и в
обычный индексный дескриптор этого файла будет записана ссылка на теневой индексный
дескриптор. Теневой индексный дескриптор не имеет специального формата, он
представляет собой точно такой же индексный дескриптор, как и обычный, но с указанием в
поле типа дескриптора на то, что он – теневой.

Расширенные права доступа хранятся в специальном файле, который создается в момент

назначения таких прав. Теневой дескриптор указывает на этот специальный файл. В Solaris
разрешено создавать не более 1024 записей в таком файле, следовательно, расширенные
права доступа могут содержать не более 1024 специфических определений прав. Этого с
избытком хватает для установки каких угодно специфических прав доступа. Каждая запись
ACL занимает 12 байт, поэтому обычно эти записи не требуют много места на диске. Однако,
при назначении специфических прав доступа большому числу объектов в файловой системе
следует помнить о том, что для этого требуется дополнительный объем дисковой памяти.

Для назначения и просмотра расширенных прав доступа используются команды setfacl и

getfacl.

оптимизация размеров разделов

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

Когда требуется установить новый сервер Solaris, стоит подумать, чем этот сервер будет
занят. В современном мире задачи компьютеров меняются быстрее, чем оборудование. Если
пять лет назад почтовый сервер, обслуживающий сто пользователей, мог работать на
медленном компьютере с диском 1 Гб, то нынче с почтой связано намного больше задач, чем
просто прием, передача и хранение. Современный почтовый сервер для тех жа ста
пользователей принимает почту, проверяет ее на вирусы, блокирует спам, возможно,
выполняет контекстный анализ письма для фильтрации спама, и только после этого сохраняет
на диске. Объемы передаваемой почты тоже существенно возрасли. Письма часто
отправляются в формате HTML, а многие адресаты вкладывают в письма не только текстовые
документы, но и фотографии, музыкальные файлы и видеоклипы. Поэтому, планируя с
запасом свой новый почтовый сервер, вы не ошибетесь. Сейчас средний пользователь хранит
в своем почтовом ящике несколько гигабайт информации, следует ожидать, что в ближайшее
время придется оценивать возможную нагрузку на файловую систему почтового сервера
исходя из десятков гигабайт на каждого пользователя. Разумеется, наш прогноз не относится
к серверам, которые только передают почту, но не хранят почтовые ящики пользователей.

Для передачи и приема нескольких писем в секунду придется установить новый компьютер с
новым процессором Pentium IV, если на сервере будет запущена программа контекстного
анализа писем для фильтрации спама (например, spamasassin). Объем памяти, естественно,
тоже должен быть достаточным для одновременного запуска десятков копий программы
sendmail или ее аналога.

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

В Solaris размер корневой файловой системы / вполне может быть менее 3 Гб. Даже с учетом
возможного обновления системы этого достаточно. Но файловая система /opt, куда будут
устанавливаться все новые пакеты, должна быть спланирована с запасом. Если работа
сервера будет связана с большой дисковой нагрузкой (кэширование http-запросов, хранение
файлов или почты), то для этих специфических целей (например, кэш http-запросов) можно
выделить отдельный раздел и назначить ему такой размер, который соответствует вашим
потребностям.

Надо будет учесть такие факторы, как возможный рост потребностей, требуемая
производительность (для подсистем SCSI лучше установить 6 дисков по 9 Гб, чем один
размером 54 Гб – будет быстрее) и не забыть учесть «запас», который создает система на
каждом разделе6.

как узнать, сколько места осталось на диске?

Оценить текущее использование диска поможет прграмма df:

#df
/ (/dev/dsk/c0d0s0): 1787406 blocks 419477 files
/boot (/dev/dsk/c0d0p0:boot): 19452 blocks -1 files
/proc (/proc ): 0 blocks 2896 files
/etc/mnttab (mnttab ): 0 blocks 0 files
/dev/fd (fd ): 0 blocks 0 files
/var/run (swap ): 1265832 blocks 30240 files
/tmp (swap ): 1265832 blocks 30240 files
/export/home (/dev/dsk/c0d0s7 ): 7647080 blocks 481212 files

Чтобы получить более удобную картину, в которой размер занятых блоков приводится в
килобайтах, следует дать команду df –k:

#df –k
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0d0s0 1857844 964142 837967 54% /
/dev/dsk/c0d0p0:boot 11234 1508 9726 14% /boot
/proc 0 0 0 0% /proc
mnttab 0 0 0 0% /etc/mnttab
fd 0 0 0 0% /dev/fd
swap 632924 20 632904 1% /var/run
swap 633208 304 632904 1% /tmp
/dev/dsk/c0d0s7 3823549 9 3785305 1% /export/home

Команда

df –o i

сообщит о количестве свободных и занятых индексных дескрипторов на разделе. Обратите

6 см. «минимальное свободное пространство»

61
внимание на то, что в других UNIX это делается с помощью команды

df -i

Для оценки размеров подкаталогов любого каталога используйте du. Например, для
определения того, сколько места на дисках занимают подкаталоги корневого каталога, дайте
команду du –s /*:

#du –s /*
2 /bin
3011 /boot
87255 /cdrom
1424 /core
3068 /dev
76 /devices
6262 /etc
26 /export
6 /floppy
4 /format.log
1 /home
20702 /kernel
2 /lib
16 /lost+found
2 /Mail
2 /mnt
1 /net
2 /nsmail
14 /opt
3822 /platform
730131 /proc
50 /qq
2 /qqqq
34154 /sbin
640 /tmp
46 /TT_DB
1811752 /usr
46138 /var
0 /vol
19 /xfn

В этой команде ключ –s указывает, что следует выдать суммарные значения по всем
подкаталогам, а аргумент /* требует, чтобы была посчитана статистика по всем подкаталогам
и файлам корневого каталога. Без указания ключа –s программа du сообщит о том, сколько
места занимает каждый из «листьев» дерева каталогов, т.е. выдаст длинный и подробный
список всех подкаталогов вообще, включая подкаталоги подкаталогов подкаталогов...

Минимальное свободное пространство

При создании файловой системы часть раздела диска резервируется на всякий случай. Эта
доля задается параметром minfree (параметр free при запуске программы mkfs) и по
умолчаниюсоставляет 10% общего объема файловой системы. Ко всяким случаям относят
переполнение диска, т.е. превышение выделенного лимита пространства размещенными на
разделе файлами , необходимость срочно найти свободный дисковый блок, когда диск почти
заполнен и тому подобное. В современных системах, где файловые системы размером в
сотни гигабайт обычны, 10% свободного объема составляет значительный объем дискового
пространства.

62
Чтобы уменьшить такие параноидальные издержки, значение minfree достаточно установить
равным 1%. Кстати при установке Solaris 9 на мой ноутбук ThinkPad 390X с диском размером
4 гигабайта, по умолчанию файловая система была создана именно с таким minfree.
Несмотря на это, документация на mkfs_ufs утверждала, что 10% является значением по
умолчанию. При создании файловой системы минимальное свободное пространство можно
задать так:

mkfs_ufs –o free=1

или так:

newfs –m 1

Изменить параметры файловой системы можно с помощью программы tunefs.

После того, как на диске осталось менее minfree процентов свободного пространства,
запись на диск сможет выполнить только root.

фрагментация

Любая файловая система так или иначе ищет компромисс между бесконтрольной
фрагментацией, как в системе FAT, и полным запретом на фрагментацию, как в файловой
системе ОС RT-11. Одной из проблем FAT является необходимость регулярно
дефрагментировать раздел, а в файловой системе RT-11 приходилось регулярно выполнять
программу squeese, которая записывала друг за другом, последовательно, все файлы,
разбросанные по диску. Фрагментация FAT приводила к снижению производительности
ввода-вывода, а запрет на фрагментацию в RT-11 делал невозможным запись на диск
большого файла, даже если на диске было полно участков с размером хоть чуть меньше его
длины, так как файл должен был быть записан только в последовательно расположенные
блоки.

В файловой системе проблема фрагментации решается очень изящно. Фактически,

фрагментация диска редко превышает 1-2% от его объема, что в мире Windows считается
превосходным показателем.

Как удается достичь такого? Нужно ли что-то делать системному администратору, чтобы
фрагментация не мешала производительности в UNIX?

Фактически, термин «фрагментация» в UNIX означает явление, совсем не похожее на

фрагментацию в FAT. В UFS если на диск записывается файл размером меньше блока, ему
выделяется фрагмент блока, но фактически «резервируется» целый блок, и файл, таким
образом, имеет резерв для расширения до размера блока. Файлы размером больше блока
записываются в свободные (по-возможности, последовательные) блоки файловой системы.
Однако размер файла не всегда кратен длине блока, поэтому последний из блоков, в которые
записан файл, будет, скорее всего, заполнен не до конца. В этот блок в UFS можно записать
фрагмент другого файла. В этом смысле «фрагментом» файла в UFS называется часть файла,
меньшая по размеру, чем блок. Фрагменты одного файла не могут храниться в разных блоках.
Это означает, что файл не может занимать более одного блока неполностью. Это
иллюстрирует Рис. 9

63
файл А А Б файл Б

блок 1 блок 2 блок 3

Рис. 9 Фрагментация в UFS

Индексный дескриптор хранит достаточно информации для того, чтобы идентифицировать

не только блок, но и номер фрагмента в блоке, когда речь идет о размещении файла на диске.

Фрагментации в том смысле, в котором она мучает пользователей Windows, в файловой

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

Как много фрагментов (в понимании UFS) на разделе, можно выяснить, дав команду fsck –n.

Для уменьшения числа фрагментов (в понимании FAT), т.е. частей файла, записанных на
разделе в разных цилиндрах вдали друг от друга, для записи файла в последовательные
блоки, следует воспользоваться коммерческими программами дефрагментации (см.,
например, http://www.eaglesoft.com/products.html – только для платформы SPARC) или
выполнить резервное копирование всех файлов раздела и обратное их восстановление
посредством программ ufsdump / ufsrestore.

изменение размеров раздела

Для изменения размеров раздела UFS можно воспользоваться программой growfs. Кроме
этого, если изменить размер раздела по какой-либо причине не представляется возможным,
следует установить новый диск и перенести часть информации на него, возможно, создав
соответствующие символические ссылки на переполненном разделе. Подробнее об
изменении размеров разделов дисков и повышении их производительности рассказано в
лекции 20.

проверка файловых систем

Аналогом широко известной из систем Windows программы scandisk в UNIX является
программа fsck. В Solaris fsck по умолчанию проверяет все фаловые системы,
перечисленные в /etc/vfstab. Обычно имеет смысл запускать fsck вручную с указанием
конкретной файловой системы:

fsck /dev/dsk/c0d0s7

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

Если в настоящий момент файловая система смонтирована, fsck не начинает проверку такой
файловой системы,. Это правило можно обойти, если потребовать от fsck обращаться к
диску как к символьному устройству, а не как к блочному:

64
fsck /dev/dsk/c0d0s7
/dev/dsk/c0d0s7 is a mounted file system, ignored
fsck /dev/rdsk/c0d0s7
** /dev/rdsk/c0d0s7
** Currently Mounted on /export/home
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
2 files, 9 used, 3823540 free (20 frags, 477940 blocks, 0.0% fragmentation)

Концепция, устройство и администрирование ZFS.

Концепция ZFS

Новая 128-разрядная файловая система ZFS была разработана компанией Sun Microsystems
для удовлетворения растущих потребностей индустрии. В ее основу положены несколько
базовых принципов, которы мы обсудим ниже, а затем перейдем к обсуждению их
реализации и конкретным приемам администрирования. Вот эти принципы:
1. организация всего доступного дискового пространства в единый пул
2. сквозной контроль целостности данных
3. транзакционность
4. легкость администрирования
Рассмотрим их значение подробнее.

Пулы накопителей вместо разрозненных дисков

Когда запускается какое-нибудь приложение (например, по команде ls – то самое, что покажет
вам список файлов в текущем каталоге), оно может запросить у операционной системы
определенный объем памяти. Что будет, если не запросит? Ничего страшного: получит
минимально необходимое пространство, размер которого указан в заголовке исполняемого
файла. А если все-таки запросит, то уж точно не станет указывать, в какой конкретно
микросхеме памяти или на каком модуле DIMM ей хочется эту память получить. Потому что
от приложения механизм реализации его запроса скрыт.
Ровно в этом и состоит прицип создания пулов накопителей – администратор просто создает
пул (это – логическая сущность, т.е. при создании пула возникает его описание в системе –
никаких физических объектов не создается), и добавляет в пул имеющиеся в наличии
накопители. Например, единственный жесткий диск того компьютера, для работы на котором
и создается пул.
Затем администратор волен создать одну или несколько файловых систем внутри пула. Их
размер может быть каким угодно – лишь бы хватило физического объема пула. О
фактическом размещении файлов и каталогов на одном или нескольких физических
носителях внутри пула позаботится драйвер ZFS. Таким образом, при применении ZFS
исчезают проблемы, связанные с ошибочным или недальновидным разбиением дисков на
разделы – теперь вы можете устанавливать и снимать ограничения на размер той или иной
файловой системы динамически, без всякой связи с физическими размерами дисков или
разделов, объединенных в пул.

65
Сквозной контроль целостности
До последнего времени проверка целостности каждого блока данных, который считывается с
диска, казалась неоправданной тратой процессорного времени. Однако сейчас, с
лавинообразным ростом мощности процессоров, это оказалось совсем недорого по
сравнению с ценой потерь от порчи данных.
Под сквозным контролем целостности понимается запись на диск контрольной суммы для
каждого блока данных, причем контрольная сумма и данные специально разносятся
максимально далеко друг от друга для снижения вероятности их совместной порчи. Если в
пуле несколько устройств, то для данных, размещенных на одном из них, контрольная сумма
будет записана на другом. Контрольные суммы вычисляются не только для данных, но и для
метаданных, и получается, что в пуле всегда есть контрольная сумма для каждого блока
информации.
При считывании любого блока подсчитывается его контрольная сумма и результат
сравнивается с контрольной суммой, хранящейся на диске. В случае расхождения ошибка
сразу обнаруживается. Разумеется, если в пуле не было запланировано никакого
резервирования (ни RAID-Z, ни иного), то ошибку уже не исправишь, но зато испорченные
данные не будут выданы за истинные.
Смысл сквозного контроля целостности данных в том, чтобы предотвратить скрытую
незаметную порчу данных в результате сбоя оборудования или встроенного программного
обеспечения диска или контроллера. Несмотря на то, что вероятность такого события кажется
низкой, некоторые исследования показывают, что она вполне значима для организаций
разного масштаба. Например, такие данные есть в отчете CERN от 8 апреля 2008 года[1].
Функциональность сквозного контроля целостности пока предоставляет всего одна файловая
система в мире – ZFS.
Разумеется, обеспечить гарантированную сохранность и неизменность данных с момента их
записи на диск до момента считывания позволяют только те или иные средства
резервирования. Поэтому, если у вас всего один раздел одного жесткого диска, то лучшее, что
может предложить ZFS – это проинформировать вас о том, что с данными непорядок.

Эта функциональность реализована и в других файловых системах, отличие ZFS в том, что
256-битные контрольные суммы блоков сохраняются не вместе с блоками, а в блоке
адресации верхнего уровня, т.е. вместе с адресом блока хранится контрольная сумма
адресуемого блока данных. Контрольные суммы считаются по любому объекту, не только по
блоку данных, но и по блоку адресации, и если в блоке адресации из-за сбоя при хранении
оказался неверный адрес, то система сама определит, что адрес неверный и ошибочные
данные просто не будут выданы по запросу (рис. 10).

66
Рис. 10: Дерево данных и метаданных ZFS

Таким образом, даже если никакого резервирования вы не предусмотрели, ZFS с бОльшей

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

67
Транзакционность
Транзакционность ZFS обеспечивается тем, как данные записываются на диск. Операции
записи группируются в транзакции, а те, в свою очередь – в группы транзакций. Каждая
транзакция, состоящая из операций записи в разные файлы, выполняется так: вначале в
свободные блоки пишутся данные, затем записываются метаданные, относящиеся к
модифицированным файлам; если запись не прошла до конца, изменения в файлах нигде не
будут учтены. Никакой коррекции метаданных в таком случае никогда не требуется, о
программе fsck можно забыть. Это иллюстрирует рис. 10. Применяемая в ZFS схема
называется “copy on write” (копирование-при-записи), что означает, что по ходу записи новых
данных старые не перезаписываются, а остаются записанными “рядом”, в других блоках, и
файл считается окончательно измененным только после изменения всех метаданных.
Это – существенное преимущество ZFS по сравнению с журналируемыми файловыми
системами, которые широко используются в последние годы во всех операционных системах.
Дело в том, что при наличии журнала возможна ситуация, когда приложение инициировало
две последовательные операции записи на диск, и при этом одна прошла успешно, а до
завершения второй произошел, скажем, сбой питания. В такой ситуации файл на диске
окажется “недомодифицированным”, хотя благодаря журналу метаданные могут остаться
согласованными.
В случае с ZFS файл никогда не будет считаться модифицированным до того, как все
метаданные – с самого нижнего уровня адресации до самого верхнего – не будут корректно
изменены.

Легкость администрирования
Следствием продуманной концепции ZFS стало значительное облегчение работы
администраторов с ней. В самом деле, например, для добавления дискового пространства
достаточно дать одну-единственную команду, включающую в пул новый накопитель.
Но самое впечатляющее – это то, что теперь можно делать резервные копии всей файловой
системы в разгар работы, мгновенно, и всего одной командой! Подробности рассказаны
ниже, в разделе “ZFS в работе” в секции “снимки и резервное копирование”.

ZFS в работе

элементы файловой системы

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

● пул (пул памяти) – набор виртуальных устройств для размещения на них данных
● данные – информация, хранимая в файлах, каждый из которых имеет имя; в отличие
от метаданных, которые хранятся в выделенных блоках и не имеют имен.
● Метаданные – служебная информация, описывающая объект; например, если объект –
это файл, то метаданные включают набор прав доступа к файлу (access control list), тип
файла, размер файла, время модификации файла, информацию о виртуальных блоках,

68
 в которых размещен файл и т.п.
● RAID-Z – массив дисков, на которые записываются данные и соответствующие им
избыточные блоки четности; в ZFS реализованы одинарная и двойная избыточность,
позволяющие исправлять однократные и двукратные ошибки в данных соответственно
● моментальный (или мгновенный) снимок – зафиксированное на определенный момент
времени состояние файловой системы – всех данных и метаданных
● клон файловой системы – ее моментальный снимок, в который разрешена запись
● набор данных (dataset) – файловая система, моментальный снимок, клон файловой
системы.

ZFS обеспечивает непротиворечивый формат хранения данных – посредством

транзакционной модели копирования при записи. Эта модель гарантирует, что данные на
диске никогда не перезаписываются, а все операции записи являются атомарными.7

Программное обеспечение ZFS состоит из семи частей:

SPA (Storage Pool Allocator)
DSL (Dataset and Snapshot Layer)
DMU (Data Management Layer8)
ZAP (ZFS Attribute Processor)
ZPL (ZFS POSIX Layer)
ZIL (ZFS Intent Log)
ZVOL (ZFS Volume)

Структуры, располагающиеся на диске, ассоциированы с этими семью частями. Чтобы не

вдаваться в излишние подробности, здесь мы рассматриваем только одну из этих частей, SPA.
Для более глубокого изучения можно порекомендовать документ “ZFS on-disk specification”[2]
со страницы разработчиков ZFS http://opensolaris.org/os/community/zfs/docs.

виртуальные устройства (vdev), метки виртуальных устройств и

загрузочный блок

Виртуальные устройства

Пул ZFS9 собирается из нескольких виртуальных устройств. Виртуальные устройства (vdev)

бывают физическими (их иногда называют leaf vdev, т.е. “устройства нижнего уровня”,
листья в дереве устройств) и логическими (их иногла называют interior vdev, “внутренними
устройствами”, потому что они находятся внтури дерева устройств. Физические виртуальные
устройства – это пригодные для записи блочные устройства, например, жесткие диски.
Логические виртуальные устройства – это логические группы физических устройств.
7 если вы не поняли этот абзац, это нормально, читайте дальше. Данные на диск в ZFS пишутся так, чтобы
любая запись либо успешно завершалась, либо не учитывалась вообще, потому что вначале пишутся
данные, а затем – метаданные, и если происходит сбой, препятствующий завершению записи, на самом
верхнем уровне метаданных об этой операции ничего не будет известно, и все место, куда происходила
неудавшаяся запись, будет считаться пустым. А запись верхнего уровня метаданных – это как раз атомарная
операция (т.е. неделимая на части), и она представляет собой запись одного блока на диск. - прим.
переводчика
8 В оригинале так, но логичнее предположить, что DMU – это Data Management Unit, а не Layer. Был бы Layer,
было бы DML.
9 ZFS storage pool здесь и далее называется просто “пул” или “пул ZFS”, потому что каждый раз писать “пул
хранения” довольно глупо: никаких других пулов на горизонте не наблюдается.

69
Виртуальные устройства образуют древовидную структуру, листьями которой являются
физические устройства. Каждый пул имеет специальное логическое виртуальное устройство,
которое считается корневым (root). Все прямые потомки корневого устройства называются
виртуальными устройствами верхнего уровня. Рисунок 11 показывает дерево виртуальных
устройств некоего пула, содержащего два зеркала. Первое зеркало, M1, содержит два диска, A
и B. Второе зеркало, M2, содержит другие два диска, С и D. Виртуальные устройства A, B, C,
D – это физические виртуальные устройства. M1 и M2 – логические виртуальные устройства,
которые являются виртуальными устройвами верхнего уровня, так как они находятся
непосредственно под корневым виртуальным устройством.

Рис. 11: Пример дерева виртуальных устройств

Метки виртуальных устройств

На каждом физическом виртуальном устройстве в пуле записывается структура размером 256

Кб, которая называется меткой виртуального устройва. Эта метка описывает то устройство,
на котором она записана и, кроме того, все устройства, которые в этом пуле имеют предком то
же самое виртуальное устройство верхнего уровня (да-да, самого верхнего, под корневым!).
Например, метка виртуального устройства С на рисунке 1 будет описывать следующие
виртуальные устройства: С, D и M2. Содержание метки виртуального устройства детально
разобрано ниже.

Метка виртуального устройства служит двум целям: предоставлению доступа к пулу в целом
и проверке его целостности и доступности устройств в нем. Чтобы метка всегда содержала

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

Избыточность
На каждом физическом виртуальном устройстве в пуле хранится четыре копии метки
устройства. За исключением короткого времени во время изменения метки, все четыре копии
идентичны и любая из них может быть использована для доступа к пулу и проверки его
содержимого. Когда устройство добавляется в пул, ZFS помещает две метки в начало
устройства и две – в конец. Рисунок 12 показывает метки, размещенные на диске размера N:
L0 и L1 – метки в начале диска, метки L2 и L3 – в конце.

Рис. 12: Четыре копии метки виртуального устройства, размещенные на устройстве

(диске) размера N

Если отталкиваться от предположения, что повреждения на диске случаются как правило в

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

Транзакционное двухэтапное обновление меток

Местоположение меток фиксируется в момент добавления устройства в пул, и стало быть
метки – это единственный объект в ZFS, который оказался вне концепции копирования при
записи. Когда метка изменяется, ее содержимое перезаписывается. Каждый раз, когда
перезаписывается содержимое диска, возникает потенциальная опасность сбоя. Чтобы
гарантировать доступность метки в любой момент, используется поэтапное изменение: на
первом этапе на диск записываются четные копии меток (L0 и L2). Если в любой момент этой
записи произойдет сбой, останутся верные метки с нечетными номерами. Как только четные
метки записаны на диск, начинается запись нечетных меток – L1 и L3. Эта процедура была
специально разработана для того, чтобы на диске в любой момент времени присутствовала
правильная копия метки устройства.

Содержание метки виртуального устройства

Метка виртуального устройства делится на 4 части: 8 Кб свободного пространства, 8Кб для

заголовка загрузочного блока, 112 Кб для содержимого в виде пар “имя/значение” и 128Кб
для ста двадцати восьми однокилобайтных структур типа uber-блок. На рисунке 13 показано,
из чего состоит метка, и следеющие четыре раздела рассказывают об этом подробнее.

71
Рис. 13: Элементы метки виртуального устройства (свободное место, заголовок
загрузочного блока, пары имя/значение, массив uber-блоков)
ZFS поддерживает и метки диска VTOC, и метки EFI в качестве допустимых описателей
разметки диска. Метки EFI пишутся в отдельную область диска, а метки VTOC – в первые
8Кб первого раздела диска. Поэтому из сообржений совместимости первые 8 Кб метки
виртуального устройства оставлены пустыми.

Заголовок загрузочного блока

Заголовок загрузочного блока размером 8 Кб зарезервирован на будущее и будет описан в
будущем приложении к этому документу.

Список пар имя/значение

Следующие 112 Кб метки виртуального устройства заняты набором пар имя/значение,
которые описывают это виртуальное устройство и все связанные с ним виртуальные
устройства; так, метка на устройстве “А” (рисунок 11) будет содержать информацию об
устройствах “А”,”В” и “M1”.

Uber-блок
Сразу за списком имен/значений в метке виртуального устройства идет массив uber-блоков.
Uber-блок – это часть метки, необходимая для того, чтобы иметь доступ к содержимому
пула10. В каждый момент времени всего один uber-блок в пуле считается активным, а именно
тот, который имеет самый большой номер группы транзакций и корректную контрольную
сумму, рассчитанную по алгоритму SHA-256.

Чтобы гарантировать постоянный доступ к активному uber-блоку, он никогда не

перезаписывается. Все изменения в uber-блоке записываются в какой-нибудь другой элемент
массива uber-блоков. При записи нового uber-блока номер группы транзакций и метка
времени увеличиваются, делая его таким образом новым активным uber-блоком за одну
атомарную операцию. Uber-блок из массива для записи при очередной транзакции
выбирается на основе алгоритма кругового выбора. На рисунке 14 два uber-блока из массива
показаны в развернутом виде.

10 uber-блок по смыслу похож на супер-блок в UFS – прим. авт.

72
Рис. 14: Массив uber-блоков; содержимое uber-блоков

Uber-блок крупным планом

Uber-блок записывается с родным для данного компьютера порядком байт11 и содержат:

ub_magic
Специфическое поле, 64-битное целое, идентифицирующее данное устройство как
содержащее данные ZFS. Значение поля – 0x00bab10c (oo-ba-block, произносится схоже с
uberblock). Таблица показывает значения поля в зависимости от порядка байт так, как они
записываются на диски:

Machine Endianness Uberblock Value

Big Endian 0x00bab10c
Little Endian 0x0cb1ba00

ub_version
Поле используется для указания формата, в котором на диске хранятся данные. В настоящее
время определено только значение 0x1. Это поле должно содержать то же значение. что и
поле “version”, описанное в разделе 1.3.3.

ub_txg

11 здесь и далее мы переводим термин big endian (в младших адресах памяти располагаются более значимые
байты) как “тупоконечный” и little endian (в младших адресах памяти располагаются менее значимые байты)
как “остроконечный” порядки байт. Тупоконечный порядок характерен для процессоров SPARC, а
остроконечный – для Intel и AMD. Термины я впервые услашал от Игоря Николаева из СПбГУ при
обсуждении того, что переводы “обратный” и “прямой” порядок неявно подразумевали некую
“правильность” того или иного варианта, в то время как на самом деле и тот, и другой порядки имеют равное
право на существование.

73
Все операции записи в ZFS выполняются группами транзакций. Каждая группа
ассоциируется с определенным номером транзакции. Значение ub_txg показывает, в пределах
какой группы транзакций был записан этот uber-блок. Чтобы это значение считалось
корректным, надо, чтобы оно должно быть больше или равно значения поля txg, хранящегося
в nvlist для этой метки виртуального устройства.

ub_guid_sum
Это поле служит для проверки доступности устройств внутри пула.
Пока пул используется, драйвер ZFS пробегает все физические устройства пула и суммирует
значения GUID с каждого устройства в пуле (значение хранится в паре имя/значение с
именем guid в списке пар имя/значние, как описано в разделе 1.3.3). Подсчитанная сумма
сравнивается с ub_guid_sum для того, чтобы подтвердить доступность все устройств в пуле.

ub_timestamp
Время, когда был записан этот uber-блок - в секундах, отсчитанное с 1 января 1970 (часовой
пояс UTC).

ub_rootbp
ub_rootbp - это структура blkptr, содержащая расположение MOS. И MOS, и blkptr описаны в
главах 4 и 2 этого документа соответственно.

указатели блоков и блоки косвенной адресации

Данные пересылаются между памятью и диском блоками. Указатель блока blckptr_t – это 128-
байтная стурктура ZFS, которая нужна для того, чтобы описать физическое расположение
блока на диске, описать сам блок и иметь возможность проверить его целостность. Структура
указателя блока показана на рис. 15.

74
 Рис. 15: Побайтовая структура указателя блока

Виртуальный адрес данных (DVA – Data Virtual Address)

Виртуальный адрес данных – это комбинация полей vdev и offset указателя блока, например,
комбинация значений поля vdev1 и поля offset1 дает виртуальный адрес dva1. ZFS позволяет
иметь до трех копий данных, на которые указывает данный указатель блока. Каждая копия
имеет свой виртуальный адрес – dva1, dva2 и dva3 соответственно. По каждому из этих
адресов хранятся совершенно одинаковые данные. Количество используемых виртуальных

75
адресов в указателе блока основано на политике12 файловой системы и называется
“шириной” указателя блока, обычный указатель (1 DVA), указатель двойной ширины (2 DVA)
и тройной ширины (3 DVA).

Поле vdev (32-разрядное целое) каждого DVA в указателе блока однозначно идентифицирует
виртуальное устройство, на котором хранится блок. Поле offset (63-разрядное цулое) – это
адрес блока на устройстве, отсчет начинается сразу после меток виртуального устройства L0
и L1 и загрузочного блока – в пределах того устройства, на котором хранятся данные. Vdev и
offset вместе определяют уникальное адрес блока данных. В поле offset указывается адрес в
секторах (т.е. в кусках пространства по 512 байт).

Для того, чтобы найти смещение физического блока в байтах от начала раздела (slice),
значение поля offset следует сдвинуть влево на 9 разрядов (29 =512) и затем сложить с
0x400000 (размер двух меток устройства vdev_label и загрузочного блока):

physical block address = (offset << 9) + 0x400000 (4MB)

GRID
Поле зарезервировано для последующего использования в отказоустойчивах конфигурациях
Raid-Z.

GANG
Группирующий (gang) блок – это блок, содержащий указатели на блоки. Группирующие
блоки используются в случае если запрошенное дисковое пространство невозможно
выделить одним непрерывным блоком. В этом случае выделяются несколько блоков
меньшего размера так, чтобы их суммарный размер был равен запрошенному, и создается
группирующий блок, в котором будут храниться указатели для выделенных блоков.
Приложению, которое запросило дисковое пространство, возвращается указатель на
группирующий блок, что создает у него “ощущение” того, что ему выделен единственный
блок.

Группирующий блок идентифицируется установленным битом “G”:

значение бита “G” Описание

0 обычный блок
1 группирующий блок
Табл. 9: Значения бита G

Группирующий блок имеет размер 512 байт и сам содержит свою контрольную сумму. Он
может содержать до 3 указателей на блоки, за которыми следует 32-разрядная контрольная
сумма. Формат группирующего блока описывает следующая структура:

12 по состоянию на август 2007 года политика такая: самые важные метеданные пишутся с тройным
резервированием (3DVA), менее важные метаданные – с двойным (2 DVA), а просто данные – без
резервирования вовсе (1 DVA).

76
typedef struct zio_gbh {
blkptr_t zg_blkptr[SPA_GBH_NBLKPTRS];
uint64_t zg_filler[SPA_GBH_FILLER];
zio_block_tail_t zg_tail.;
} zio_gbh_phys_t;

zg_blkptr: массив указателей на блоки. Каждый 512-байтный группирующий блок

может содержать до 3 указателей на блоки.

zg_filler: поле заполнителя (filler) требуются для того, чтобы дополнить

группирующий блок до 512 байт.

typedef struct zio_block_tail {

uint64_t zbt_magic;
zio_cksum_t zbt_cksum;
}

zbt_magic: специфическое значение, завершающее блок ZIO. Равно

0x210da7ab10c7a11 (zio-data-bloc-tail).

typedef zio_cksum {
uint64_t zc_word[4];
}zio_cksum_t;

zc_word: четыре 8-байтных слова, содержащих контрольную сумму группирующего

блока.

cksum (Контрольная сумма)

По умолчанию в ZFS контрольная сумма вычисляется для всех данных и метаданных.
Поддерживается несколько алгоритмов контрольного суммирования, в том числе fletcher2,
fletcher4 и SHA-256 (256-bit Secure Hash Algorithm из FIPS 180-2, подробнее на странице http://
csrc.nist.gov/cryptval). Какой алгоритм использовать для вычисления контрольной суммы
этого блока, определяется значением 8-разрядного целого в поле cksum указателя блока. В
нижеследующей таблице приводится соответствие значений алгоритмам.

Описание Значение Алгоритм

включено 1 fletcher2
выключено 2 none
метка 3 SHA-256
заголовок группир. блока 4 SHA-256
zilog 5 fletcher2
fletcher2 6 fletcher2
fletcher4 7 fletcher4
SHA-256 8 SHA-256
Табл. 10: Значения поля cksum и соответствующие алгоритмы контрольного суммирования

77
comp (Сжатие)
ZFS поддерживает несколько алгоритмов сжатия. Какой тип сжатия использовать для данного
блока, определяется полем comp указателя блока:

Описание Значение Алгоритм

on 1 lzjb
off 2 нет сжатия
lzjb 3 lzjb
Табл. 11: Значения поля comp и соответствующие алгоритмы сжатия

Размер блока
Размер блока определяется тремя разными полями в указателе блока:
psize, lsize, and asize.
lsize: логический размер. Показывает размер данных без учета сжатия, программного
RAID (RAID-Z) или накладных расходов, связанных с группирующими блоками (gang).
psize: физический размер блока на диске после сжатия
asize: фактически занятое данными пространство, общий размер всех блоков, занятых
для хранения этих данных, включая заголовки группирующих блоков или блоки
четности RAID-Z.

Если сжатие данных не включено, и ZFS организовано без RAID-Z, то значения lsize, asize,
и psize одинаковы. Все эти значения записываются как количество 512-байтных секторов
минус один, которые занимает блок.

Порядок байт в слове

Endian Value
Little Endian 1
Big Endian 0
Табл. 12: Значения поля E (порядок байт в слове)

ZFS легко адаптируется к переносу между компьютерами разной архитектуры, даже если в
них используется различный порядок байт в слове – тупоконечный (big endian, в младших
адресах памяти располагаются более значимые байты, SPARC) или остроконечный (little
endian, в младших адресах памяти располагаются менее значимые байты, x86). Поле E
указателя блока (от Endianness) содержит 1 для блока, записанного в остроконечном порядке
байт (x86), и 0 – для блока, записанного в тупоконечном порядке (SPARC). Данные всегда
пишутся на диск в формате того компьютера, на котором это происходит. Если пул
перемещается из компьютера с одним порядком байт на компьютер с другим порядком байт,
содержимое блока конвертируется в новый порядок при чтении, а на диске старое
содержимое остается в прежнем формате.

Тип данных в блоке

Поле типа данных в указателе блока показывает, какой тип данных хранится в этом блоке,

78
Типов немало, и они перечислены в таблице 13.
Тип Значение
DMU_OT_NONE 0
DMU_OT_OBJECT_DIRECTORY 1
DMU_OT_OBJECT_ARRAY 2
DMU_OT_PACKED_NVLIST 3
DMU_OT_NVLIST_SIZE 4
DMU_OT_BPLIST 5
DMU_OT_BPLIST_HDR 6
DMU_OT_SPACE_MAP_HEADER 7
DMU_OT_SPACE_MAP 8
DMU_OT_INTENT_LOG 9
DMU_OT_DNODE 10
DMU_OT_OBJSET 11
DMU_OT_DSL_DATASET 12
DMU_OT_DSL_DATASET_CHILD_MAP 13
DMU_OT_OBJSET_SNAP_MAP 14
DMU_OT_DSL_PROPS 15
DMU_OT_DSL_OBJSET 16
DMU_OT_ZNODE 17
DMU_OT_ACL 18
DMU_OT_PLAIN_FILE_CONTENTS 19
DMU_OT_DIRECTORY_CONTENTS 20
DMU_OT_MASTER_NODE 21
DMU_OT_DELETE_QUEUE 22
DMU_OT_ZVOL 23
DMU_OT_ZVOL_PROP 24
Табл. 13: Типы объектов

Уровень (lvl)
Это поле содержит число уровней до этого блока, т.е. количество указателей блоков, которые
надо просмотреть для того, чтобы добраться до данных в текущем блоке.

Счетчик заполненных блоков (fill count)

Счетчик заполненных блоков содержит количество ненулевых блоков под данным указателем
блоков (т.е. на более нижних уровнях дерева блоков). Это поле равно 1 для указателя на блок
данных, так как он не имеет ни одного указателя блоков ниже себя. Это поле имеет иное
значение для указателя блоков типа DMU_OT_DNODE: для таких блоков поле содержит
количество свободных дескрипторов ниже этого указателя блоков.

79
Номер породившей блок группы транзакций (birth txg)
64-битное целое поле birth txg (birth transaction) содержит номер группы транзакций, в ходе
которой данный блок был занят под информацию.

Заполнители (padding)
Три блока-заполнителя в указателе блоков зарезервированы для использования в будущем.

копирование при записи данных в ZFS (copy on write)

Предположим, что у нас есть некое дерево блоков (рис. 10). Файловые системы традиционно
представляют как дерево блоков. Любой блок данных в такой файловой системе можно
найти, пройдя по ссылкам на дочерние блоки, начав с корневого. Дерево на рисунке похоже
на двоичное, но на самом деле дерево метаданных и данных в ZFS не является таковым: оно
более широкое и менее глубокое.
Количество уровней в дереве блоков никак не соотносится с количеством уровней вложенных
каталогов в файловой системе.
Допустим, мы хотим модифицировать некий файл и поэтому надо записать новые данные в
два блока. Для этого мы записываем два новых блока с новыми данными на диск, а старые
при этом остаются такими же, как и раньше. Это показано в верхней правой части рис. 10.
Пришла пора перезаписывать метаданные, а именно блоки прямой и косвенной адресации,
которые должны указывать на наши новые блоки. Это делается посредством записи новых
блоков адресации, старые остаются такими же, как и раньше. Это показано в нижней левой
части рис. 10.
Как только будут записаны все измененные блоки данных, а также указывающие на них
блоки прямой и косвенной адресации, на диске будет записано две копии самосогласованного
состояния файловой системы — соответствующее первоначальному, изображенное синими
блоками, и соответствующее измененному состоянию, изображенное зелеными блоками.
Для того, чтобы завершить операцию записи новых данных, требуется перевести файловую
систему из первоначального в измененное состояние. Для этого надо перезаписать всего один
блок, а именно – uber-блок. Эта операция является атомарной, поскольку при ее выполнении
записывается ровно один блок на диске: ведь на диск на физическом уровне нельзя записать
данные размером меньше блока.
На самом деле uber-блок тоже не перезаписывается физически, дело в том, что в начале
каждого устройства хранится массив из нескольких uber-блоков, среди которых только один
является актуальным в каждый момент времени, и при “перезаписи” на самом деле
порисходит запись в один из “неактуальных” uber-блоков, после чего он становится
“актуальным”
Как только uber-блок записан, группа транзакций считается завершенной и файловая система
оказывается в новом, тоже самосогласованном состоянии.

снимки и резервное копирование

Кому и зачем это надо? Очень просто: представьте, что системному администратору надо
установить обновление системы или поменять версию, скажем, PHP на сервере. Раньше
осторожные руководства требовали вначале делать полную резервную копию системы, а
затем уже что-то обновлять. Но если каждый день требует каких-то новых настроек и

80
программ – не уйдет ли на резервное копирование все рабочее время?
Функциональность мгновенных снимков системы (sbapshots) дает возможность
зафиксировать состояние всей файловой системы на определенный момент времени (причем
гарантированно – все файлы фиксируются в том виде, в котором они существовали в ту
конкретную наносекунду, когда вы потребовали сделать snapshot).
А чему радоваться разработчику? Да это же настоящая находка – не надо никаких средств
архивирования версий; достаточно создать по мгновенному снимку на каждую версию
разрабатываемой программы, и двигаться дальше. Все версии ваших файлов будут сохранены
автоматически.
Разумеется, мгновенные снимки требуют места на диске – за функциональность приходится
платить. Но так как мгновенный снимок не требует копирования всех файлов (фактически
новое место требуется только под измененные после “фотографирования” файлы), то и
накладные расходы куда меньше, чем при резервном копировании всей файловой системы на
соседний диск или ленту. Плюс к тому, мгновенный снимок и создается мгновенно, никакой
траты времени на перезаписывание гигабайтов данных нет.
Сделать моментальный снимок файловой системы проще простого: он создается при
помощи команды zfs snapshot, которой следует указать имя создаваемого моментального
снимка. Имя моментального снимка указывается как filesystem@snapname:
# zfs snapshot pool/home/ahrens@friday

Здесь friday – имя моментального снимка файловой системы pool/home/ahrens.

Создать моментальные снимки всех подчиненных файловых систем можно при помощи
ключа -r.
Мгновенные снимки можно использовать для резервного копирования; и – внимание! - все
это на лету, без перехода в однопользовательский режим, в том числе – с версии Solaris
Express build 62 – и для корневой файловой системы!
Как же это устроено внутри файловой системы? Что происходит при создании мгновенного
снимка?
Как видно из рис. 2, при перезаписи файла блоки с его старым содержимым остаются
неизменными. Ничто не мешает в любой момент потребовать от системы сохранить старое
состояние всего дерева блоков файловой системы, включая метаданные. Более того,
моментальный снимок занимает мало места, так как данные, которые не изменялись с
момента создания снимка, попросту являются общими и для рабочей файловой системы, и
для снимка.
Кроме моментальных снимков можно создавать клоны файловой системы – снимки с
возможностью записи в них. Когда в любом из клонов изменяются данные, новые блоки
оказываются своими для каждого из клонов, но неизмененые данные хранятся в блоках,
общих для всех клонов.

RAID-Z
Для этого в ZFS предусмотрена реализация RAID-Z – это организация программного RAID-
массива с блоками переменной длины. Переменная длина дает значительный выигрыш в
производительности, но меняет алгоритм восстановления данных, поскольку каждый блок в
массиве может иметь разную длину. Кроме этого, в отличие от традиционных массивов
RAID, в ZFS можно организовать не только однократный, но и двукратный контроль

81
четности, и это защищает от одновременного сбоя двух физических носителей.

Легко видеть, что ZFS в самом деле гарантирует сохранность данных, если у вас достаточно
надежное оборудование – по крайней мере один диск в запасе. Кстати, ZFS поддерживает и
диски “горячего резерва” (spare disks), на которые ничего не записывается до момента, когда
один из рабочих дисков RAID-Z выйдет из строя. Зато как только понадобится, сбойный диск
будет исключен из пула дисков, а диск горячего резерва немедленно включен туда.

Для поддержки зеркалирования в ZFS реализована процедура ресинхронизации (resilvering)

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

Если же диск не дает сбоев в целом, но какая-то часть даных оказалась повреждена (т.е.
контрольные суммы не соответствуют данным), то происходит автоматическая запись на
сбойный диск данных с “правильного” диска, как показано на рис. 16. Ошибочный блок
данных показан красным цветом, корректный – зеленым. Вначале при выполнении чтения
обнаруживается ошибочный блок (расхождение с контрольной суммой), приложению
передается корректный блок данных с другого диска в зеркале, и затем сбойный блок на
первом диске замещается корректным.

Рис. 16: Самовосстановление данных

Резервирование метаданных
Все метаданные в ZFS пишутся на диск в нескольно разных мест, для большей
отказоустойчивости. В зависимости от ценности метаданных, делается три или – как
минимум – две копии. В отличие от UFS, где на диск записывается несколько копий только
суперблока, здесь делаются копии всех метаданных, причем если в пуле несколько устройств,
ZFS старается разнести копии метаданных по разным устройствам.

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

● транзакционность
● контрольные суммы в метаданных
● программный RAID (RAID-Z), типов “зеркало”, “RAID с однократной четностью”,
“RAID с двукратной четностью”
● диски горячего резерва для RAID-Z
● “самовосстановление” данных, когда они записываются с избыточностью (т.е. с
контролем четнгости или зеркалированием).
● Тройное резервирование метаданных

82
масштабируемость ZFS
Максимальный размер файла, который можно сохранить в ZFS – 264 байт, т.е. 16 экзабайт.
Это в 18 миллиардов миллиардов ( 18,4 х 1018) раз больше, чем позволяют современные 64-
битные файловые системы. Максимальный размер одной файловой системы ZFS такой же -
264 байт. Если создавать по 1000 файлов в секунду, то для достижения максимального
количества файлов в ZFS (248 штук) понадобится примерно 9000 лет. Нетрудно видеть, что
ZFS действительно создавалась так, чтобы избежать скорого достижения лимитов!
Автор проекта ZFS Джефф Бонвик (Jeff Bonwick) подсчитал, что на 100%-е заполнение
файловой системы ZFS потребуется больше энергии, чем для того, чтобы вскипятить океан.
[3]
Так, Сет Ллойд (Seth Lloyd) в 2000 году в статье “Ultimate physical limits to computation” [4]
показал, что 1 килограмм материи, ограниченный 1 литром объема, может произвести не
более чем 1051 операций над не более чем 1031 битами информации. Заполненный дло отказа
128-битный пул памяти будет содержать 2128 блоков = 2137 байт = 2140 бит. Минимальная масса,
которая вместит такое количество информации будет равна (2140 бит) / (1031 бит/кг) = 136
миллиардов килограммов.
Если вспомнить известную формулу зависимости массы и энергии E=mc2 и представить
массу такого компьютера в форме энергии, это составит 1.2x1028джоулей.
Известно, что масса всех океанов на планете примерно равна 1.2x1028
кг, и что для того, чтобы превратить в кипяток 1 кг льда требуется 400 000 джоулей, причем
скрытая энергия на испарение добавит еще 2 000 000 джоулей на килограмм, итого 2,4х106
джоулей на килограмм. Стало быть, для испарения океанов надо порядка 2.4x106 Дж/кг *
1.4x1021 кг = 3.4x1027 Дж.
Выходит, заполнить 128-битную файловую систему действительно сложнее, чем вскипятить
океан!
Конечно, в этом расчете Джефф не учел, что океан не находится в замороженном состоянии,
но – согласитесь – потенциальный объем ZFS все равно впечаталяет! И вряд ли в ближайшие
несколько десятилетий бизнес, выбравший ZFS, будет сталкиваться с проблемой
переполнения файловой системы – скорее уж перестанет хватать электричества для питания
дисковых массивов!

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

Каждая операция ввода-вывода имеет свой приоритет и связанный с ним крайний срок
выполнения. Чем выше приоритет, тем ближе крайний срок. С крайним сроком выполнения
связывается логический адрес блока (LBA) для операции записи – чем более поздний срок ей
назначен, тем меньше будет значение LBA: так достигается практически линейное движение
по диску по мере выполнения все менее и менее “срочных” операций. Операции чтения с
диска имеют больший приоритет, чем операции записи, потому что при записи асинхронный
вызов write() возвратит управление приложению как только данные попадут в кэш, а вызов
read() синхронный, потому что приложение вынуждено ждать, пока ему будут выданы
данные с диска.

83
Кроме этого, ZFS осуществляет интеллектуальную предвыборку, подбирая схему
предвыборки для каждого потребителя данных в отдельности, в отличие от других систем,
которые делают предвыборку всегда одинаково – в расчете на последовательный доступ к
данным.

При записи ZFS старается писать данные в последовательные блоки, благо схема copy-on-
write исключает модификацию уже заполненных данными блоков. ZFS также поддерживает
параллельную запись в один файл. Кроме этого, ZFS выбирает размер блока – от 512 байт до
128 Кбайт исходя из воображений производительности диска, а не его размера.

Когда в системе несколько устройств, ZFS балнсирует нагрузку на них так, чтобы
задействовать каждое с максимальной продуктивностью, и при добавлении нового диска к
пулу автоматически заполняет его новыми данными так, чтобы достичь максимальной
скорости доступа к данным. Если какое-то устройство в пуле замедлилось из-за сбоя или
заполнения значительной части его объема, ZFS старается не записывать на него новых
данных, чтобы не снижать общую скорость системы.

Встроенное сжатие данных (для каждой файловойсистемы можно разрешить компрессию) не

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

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

В чем здесь идея? Предположим, мы записали 1 байт в начале файла, затем отступили от
начала 1 гигабайт, и записали еще один значимый байт в файл. Получили файл размером в 1
гигабайт и 1 байт, который в середине содержит гигабайтное пространство, заполненное
нулями. При копировании такого файла нет смысла переписывать все эти нули, это бы
значительно снизило скорость операции. Поэтому было найдено решение, логично
вытекающее из структуры ZFS: файл в ZFS – это дерево блоков, каждый блок косвенной
адресации содержит поле, в котором указывается число блоков, лежащих одним уровнем
ниже него (см. рис. “Файл с нулевыми блоками внутри”) [5].

Строго говоря, как именно обращаться с файлами, содержащими обширные поля нулей
внутри себя, решает не файловая система, а каждое приложение индивидуально. В случае с
ZFS файловая система умеет работать с расширенной функцией lseek, в которой
поддерживаются операции SEEK_HOLE (найти следующую область нулей, размером не
менее переданного lseek аргумента) и SEEK_DATA (найти следующую за областью нулей
область единиц, не менее переданного аргумента размером). В Solaris такая
функциональность реализована, а пользоваться ей или нет – дело разработчика программы.

L4 6
-----------------------------------
L3 5 0 1
----------- ----------- -----------
L2 3 0 2 0 0 1
--- --- --- --- --- ---

84
 L1 111 101 001

Рис. Файл с нулевыми блоками внутри (рисунок взят из [5]). Файл состоит из 9 блоков, три
из которых на 100% заполенны нулями.

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

Что касается цифр, то любое тестирование можно провести так, чтобы нужный продукт
выглядел более выигрышно. Поэтому все, что я считаю важным подчеркнуть в отношении
известных результатов тестирования ZFS, сводится к перечню тестовых операций, в которых
она уже показала значительное (2-6 раз) превышение производительности по сравнению с
UFS: [6]
● открытие файла, резервирование пространства под его расширение и однократная
запись в файл
● последовательная модификация (перезапись) всех данных в файле порциями по 32К
● создание файла размером в ½ свободной памяти посредством записи в него порциями
по 1Мб, затем двукратное последовательное чтение всего файла
● параллельная синхронная запись в 100-мегабайтный файл четырьмя потоками
Разумеется, количество тестов будет расти с ростом промышленного использования ZFS, так
что в скором времени появятся новые результаты тестов.

Практическое администрирование ZFS: команды

Каждый системный администратор хочет, чтобы надежность его систем и корректность прав
доступа к данным не стоила ему долгих ночных бдений. Так вот: в ZFS и резервное
копирование, и назначение прав доступа, и изменение размеров файловой системы делается
очень просто. Ощущение от перехода к ZFS можно передать аналогией с переходом от
автомобиля с ручной коробкой передач к маштине с автоматической коробкой.

Перейдем к делу: как создать пул памяти ZFS, как смонтировать файловые системы и как
модифицировать созданные системы?
Создание пула giant из двух дисков - c1t0d0 и c1t1d0
# zpool create giant c1t0d0 c1t1d0

Система ищет указанные диски в каталоге /dev/dsk, и помечает их как принадлежащие

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

85
# zpool create giant mirror c1d0 c2d0

Массив RAID-Z из нескольких дисков создается командой

# zpool create giant raidz c1t0d0 c2t0d0 c3t0d0 c4t0d0

Для создания массива с двойным контролем четности надо вместо raidz указать raidz2.
Уничтожить пул можно командой zpool destroy. Осторожно: она уничтожает пул, даже если
в нем содержатся смонтированные наборы данных.
# zpool destroy giant

Добавление устройства в пул – команда zpool add, например для добавления еще двух
устройств к зеркалу giant надо скомандовать
zpool add giant mirror c2t1d0 c2t2d0

После создания пула пора создавать файловые системы, которые будут размещаться в нем -
командой zfs create, которой требуется аргумент - имя файловой системы; оно указывается
как путь, начиная с имени пула: pool-name/[filesystem-name/]filesystem-name
Имя пула и исходные имена файловой системы в пути идентифицируют то местоположение,
где будет создана новая файловая система. Все файловые системы верхнего уровня уже
должны существовать в пуле. Последнее имя в пути идентифициреут имя создаваемой
файловой системы.
Так мы создаем файловую систему oracle в файловой системе giant/home.
# zfs create giant/home/oracle

Если создание файловой системы прошло успешно, система ZFS автоматически монтирует
ее. По умолчанию точкой монтирования считается путь, указанный в zfs create. В
нашемпримере вновь созданная файловая система oracle монтируется в
/giant/home/oracle.

Для получения информации о состоянии систем в пуле используют команду zpool

list:

# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
dbspace 340G 162G 178G 47% ONLINE -
samba 204G 134G 69.9G 65% ONLINE -
usrdb 68G 27.3G 40.7G 40% ONLINE -

Включить сжатие для файловой системы (в примере - home/archive) можно командой

# zfs set compression=on concat/archive

Квотирование и резервирование пространства

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

86
введена еще одна интересная возможность, резервирование места для файлов пользователя.
В самом деле, если вы знаете, что пользователь oracle или mail нуждается в хранении
большого количества данных, удобно гарантировать ему это хранение независимо от чьих-то
аппетитов по выкачиванию видео из Сети.
Для резервирования в ZFS следует дать несколько простых команд (только надо помнить, что
зарезервировать можно только свободное место, если его уже не хватает, то вначале надо
удалить лишнее):
# zfs set reservation=4G pool/home/oracle
# zfs get reservation pool/home/oracle
NAME PROPERTY VALUE SOURCE
pool/home/oracle reservation 4.00G local

Нельзя зарезервировать для пользователя больше места, чем дозволено квотой. При
резервировании размер зарезервированного пространства определяется последней по
порядку командой zfs set reservation, значения последовательных команд НЕ
складываются.

# zfs set quota=5G pool/filesystem

# zfs set reservation=10G pool/filesystem/user1
cannot set reservation for 'pool/filesystem/user1': size is greater than
available space

Дополнительные материалы для чтения о ZFS

ZFS Best Parctices Guide
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#ZFS_Management_Tools_.
2F_Observability
Manual setup to boot ZFS on x86 http://www.opensolaris.org/os/community/zfs/boot/zfsboot-manual/
Администрирование ZFS (перевод на русский язык): документ можно скачать со страницы
http://dlc.sun.com/osol/g11n/downloads/docs/current/ в виде архива с .html-файлами.

Литература
1: Bernd Panzer-Steindel, Data integrity, , http://indico.cern.ch/getFile.py/access?
contribId=3&sessionId=0&resId=1&materialId=paper&confId=13797
2: , ZFS on-disk specification, 2006,
http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf
3: , , , http://en.wikipedia.org/wiki/ZFS
4: Seth Lloyd, Ultimate physical limits to computation, 2000
5: Jeff Bonwick, , , http://blogs.sun.com/bonwick/
6: , , , http://blogs.sun.com/roch/entry/zfs_to_ufs_performance_comparison

Управление процессами и проектами.

Наилучшим методическим материалом для освоения данной темя является реководство,

опубликованное по адресу http://www.opennet.ru/docs/RUS/solaris_rmc/.

87