Файловая система

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

Термин "файловая система" в литературе используется для обозначения трех разных понятий.

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

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

В системах UNIX до 2004 года существовала только одна концепция файловых систем, основанная на представлении файловой системы компьютера как единого дерева, отдельные "ветви" которого могут быть расположены на различных физических носителях или в различных разделах одного и того же носителя. Концепция предполагала необходимость разметки любого физического носителя (часто – вручную, т.е. системный администратор должен был спланировать разметку диска и потратить некоторое время на его разметку с помощью fdisk, format или аналогичного инструмента).

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

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

С появлением больших дисковых массивов, состоящих из десятков и сотен дисков, особенно в системах, связанных с высокопроизводительными вычислениями и обработкой больших объемов данных, потребовалось собирать из физических дисков виртуальные тома. Для этого разные производители систем использовали разные приложения, среди которых большую популярность получил Logical Volume Manager (LVM) для Linux. Однако, хотя применение LVM облегчало группировку разделов в логические тома большого объема, необходимость размечать каждый диск и создавать на нем разделы сохранялась.

Поэтому в 2004 году появилась вторая концепция файловой системы, которая тоже предполагала существование единого логического дерева каталогов, но на уровне физических устройств требовала создания единого пула, из которого можно выделить произвольный объем для любой файловой системы (в смысле "логической единицы монтирования"). Эта концепция представляла дисковую память таким же образом, как виртуальную память, в которой работают процессы в 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
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). Раздел – это группа расположенных рядом цилиндров. Смысл разделения диска на разделы состоит в том, чтобы:

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

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

Каждому разделу соответствует свой файл устройства в каталоге /dev/dsk. Пространство под разделы выделяется цилиндрами. Раздел однозначно определяется номерами начального и конечного цилиндров. В Solaris принята следующая концепция именования таких файлов устройств: в имени устройства учитываются номер контроллера, SCSI ID (target number), номер диска (LUN – logical unit number) и номер раздела на диске. Если это диск IDE, то роль SCSI ID играет пара master/slave (соответственно, 0/1). Для встроенных дисков SCSI и любых дисков IDE номер диска равен 0. Это иллюстрирует рис 6.1.

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

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

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

По умолчанию при установке Solaris на IDE-диск на платформе 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, хранятся сведения о диске в целом: реальный размер, число цилиндров и т.п.

Говоря о разных типах имен устройств, можно рассмотреть пример именования разделов диска. Так, разделам 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.

Приводы для CD- и DVD-дисков

Для того, чтобы узнать, какие приводы есть в вашей системе и какие имена им назначены, можно воспользоваться prtconf или cdrecord (последняя программа может не входить в поставку Solaris, но она доступна в исходных кодах в Сети). В нижеследующем примере видно, что в компьютере установлен один привод, и если вставить в него диск, то можно увидеть, что автомонтирование диска произойдет для устройства /dev/dsk/c1t0d0s2, что соответствует устройству с параметрами 1,0,0 из вывода cdrecord.

/opt/schily/bin/cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 2.01.01a40 (i386-pc-solaris2.11)
Copyright (C) 1995-2008 Jorg Schilling
Warning: Using USCSI interface.
Using libscg version 'schily-0.9'.
scsibus1:
   1,0,0 100) 'MATSHITA' 'DVD-RAM UJ-85JS ' 'F100' Removable CD-ROM
   1,1,0 101) *
   1,2,0 102) *
   1,3,0 103) *
   1,4,0 104) *
   1,5,0 105) *
   1,6,0 106) *
   1,7,0 107) *

Каталог /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

Это пример дерева подкаталогов каталога /devices Solaris, установленного на ноутбук 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". Более подробно об изменении аппаратной конфигурации и добавлении драйверов устройств рассказывается в лекции 2 курса "Системное администрирование ОС Solaris 10".

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

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

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

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

Общим понятием для всех файловых систем, соответствующих POSIX, также является точка монтирования. Это – каталог, в котором появляется содержимое логического или физического раздела файловой системы после его монтирования. Монтирование представляет собой операцию присоединения "ветви" к дереву файловой системы и выполняется автоматически программой автомонтирования или по команде mount.

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

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

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

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

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

Обратите внимание на то, что во всех файловых системах кроме ZFS справедливо следующее: если каталог является точкой монтирования, то он находится на отдельном разделе, а если нет – то он расположен на том же разделе, что и родительский каталог. Например, каталог /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)

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 каждый раз. Например, это можно сделать так:

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/vfstabВнимание! В других системах UNIX этот файл имеет другое название – /etc/fstab . Типичный файл /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, будут проверены и смонтированы при старте системы. Файловую систему можно смонтировать в любой момент, надо лишь указать ей в качестве точки монтирования пустой каталог, который уже существует и доступен в системе. Операцию монтирования и демонтирования файловой системы может осуществить только root.

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

mount device mount_point

Например

mount /dev/dsk/c0d1s0 /test

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

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

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

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

Нельзя демонтировать занятую файловую систему. Занятой считается такая файловая система, файл с которой открыт в настоящее время кем-то из пользователей или каталог которой является текущим каталогом кого-то из работающих в системе пользователей. В разделе "Определение процессов, занявших файл" обсуждается, как выяснить, какой именно процесс занял тот или иной файл в системе (см. также fuser(1M) ).

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

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

umount mount_point

Например

umount /mnt

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

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

man rmmount

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

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

Функцию vold могут исполнять и другие компоненты системы, например, соответствующий компонент графической среды GNOME.

Суперблок

Суперблок – это блок в начале диска, содержащий общую информацию о диске и файловой системе на ней. Роль суперблока в ZFS играет uber-блок, также содержащий информацию, необходимую ZFS для работы с этим диском как с элементом пула ZFS. Суперблок в UFS содержит общую информацию о файловой системе как совокупности файлов на данном разделе жесткого диска, в частности, размер раздела UNIX, число свободных и занятых блоков и индексных дескрипторов и флаг целостности файловой системы. Подробнее о суперблоке в UFS и uber-блоке в ZFS рассказано в лекциях 7 и 8 соответственно.

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

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

Дерево каталогов

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

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

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

Основными ("родными") файловыми системами Solaris являются UFS (Unix file system) и ZFS (Zettabyte File System). Всего Solaris 10 поддерживает 14 файловых систем, перечисленных в табл. 6.2. Кроме этого, в кластерах поддерживается файловая система Lustre, разработанная компанией CFS, Inc. (от Cluster File System). Компания CFS была куплена компанией Sun Microsystems в 2007 году.

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

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

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

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

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

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

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

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

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

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

Дерево каталогов

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

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

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

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

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

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

Типы файлов

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

#ls –l /etc

lrwxrwxrwx  1 root  root     4 Янв 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-систем. Возможность запустить файл определяется исключительно правами доступа к файлу. При попытке запустить двоичный файл система будет искать в нем корректный заголовок исполняемого кода. Если этот файл на самом деле не является программой UNIX, система просто сообщит об ошибке. При попытке выполнить текстовый файл он будет рассматриваться как скрипт командного процессора (если иное не указано в первой строке файла, где можно указать иной интерпретатор). Если файл не является скриптом, командный процессор завалит вас сообщениями об ошибках. Он будет выдавать не меньше одного ругательного сообщения на каждую строку. Не пытайтесь запускать то, что не должно запускаться!

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

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

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

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

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

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

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

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

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

Из знаков препинания рекомендуется использовать только точку ".", тире "-" и подчеркивание "_". Использование других знаков (запятых, скобок, звездочки, решетки, вопросительного и восклицательного знаков и других) теоретически возможно, но неудобно. Дело в том, что командные процессоры и стандартные системные функции в 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

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

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

Символ "~" (тильда) в большинстве командных интерпретаторов обозначает домашний каталог пользователя. Например, команда

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 файл можно переместить в другой каталог:

mv file /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 каталог

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

rm –rf /usr/local/squid/

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

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

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

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

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

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

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

cd каталог

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

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

Ссылки

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

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

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) в системах Windows. При удалении символической ссылки с файлом или с каталогом, на который она ссылается, ничего не происходит. При удалении файла, на который ссылается символическая ссылка, она "повисает в воздухе", ссылаясь на пустоту. В последнем случае при обращении к такой "пустой" ссылке возникнет ошибка file not found, несмотря на то, что сама ссылка будет видна и доступна в списке файлов.

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

Определитель процессов, занявших файл

Чтобы узнать, какой процесс занимает нужный вам ресурс (файл или каталог) – достаточно использовать программу fuser. Предположим, я даю команду umount /export/home/filip и получаю сообщение Device busy. Это означает, что какой-то процесс "держит" каталог /export/home/filip. Чаще всего для решения проблемы достаточно покинуть каталог, который хочется демонтировать (сплошь и рядом такую команду дают, находясь в том же самом каталоге, что является ошибкой). Однако, если выход из каталога с помощью команды cd не помогает, можно выяснить, какой именно процесс использует каталог для своих нужд:

fuser /export/home/filip
/export/home/filip:     1464c    1457c    1216c    1206c
1080c    1078c    1077c    1032c    1026c    1012c    1010c
1004c    988c     957c     953c     950c     941c     939c
929c     916c     915c     910c     908c     896c     895c
894c     862c     861c     822c     729c

Список, который мы получили – это идентификаторы процессов. Остается только удалить из выдачи программы fuser буквы, оставив только числа – именно они и являются идентификаторами. Большой список процессов, которые мы получили в нашем примере, связан с тем, что мы пытались демонтировать домашний каталог пользователя, который в этот момент работал в системе. Разумеется, многие процессы использовали его домашний каталог тем или иным образом.

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

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

Система безопасности 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). Пользователю, который хочет обратиться к файлу, даются права доступа либо владельца, либо группы файла, либо права "всех остальных". Права доступа проверяются так (см. рис. 6.6, на примере слова прав доступа rwxrw-r-- ):

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

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

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

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

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

Старшие три бита – это бит установки владельца при запуске файла (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 файл

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

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) к файлам

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

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

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

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

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

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

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

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

Ключ -m служит для добавления прав доступа, а не для их замены. Эффективные (т.е. те, которые в самом деле будут применяться) права доступа пользователей lena и petr определяют не только их персональные права доступа к этому файлу, но и маска, которая показывает права доступа по умолчанию. Из персональных прав и маски выбираются наиболее строгие ограничения, поэтому, если в персональных правах доступа или в маске для файла 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

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

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.