Лекция 3

 

Лекция 3. 1

Работа в ОС UNIX. 2

ext3. 2

ext4. 3

RaiserFS. 3

Raiser4. 4

UFS1 (FFS) 5

UFS2. 6

JFS. 7

XFS. 8

DevFS. 8

tmpFS. 9

NFS. 9

Понятие монтировки. 9

Загрузка UNIX. Завершение работы.. 10

 


 

Работа в ОС UNIX.

 

 

Джеймс Армстронг (мл.). Секреты UNIX. Диалектика. Киев 96.

 

Сергей Дунаев. UNIX. System V. Release 4.2. Диалог МИФИ, Москва 95г.

 

Вильям Столлингс. Операционные системы. Москва. Издательский дом ``Вильямс’’. 2002.

 

Б.В.Кениган, Р.Пайк. UNIX --- универсальная среда программирования.

Финансы и статистика. Москва 92.

 

Михаэль Кофлер. Весь Linux.  Установка, конфигурирование, использование.

7-ое издание. Бином 2007г.

 

UNIX. X Window. Motif. Основы программирования (части I, II)

АО Аналитик. Москва 94.

 

ext3

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

Основное отличие от ext2 состоит в том, что это – журналируемая fs (journaling filesystem).

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

Теоретически, журналировать можно два типа данных – 1)данные о файлах и файловой системе (metadata); 2)сами данные в файлах(data). Кроме того, журналирование может идти двумя способами: 1)физическое журналирование – данные сохраняются в журнале блоками, даже если в блоке изменился один байт; 2)логическое журналирование – в журнале хранится информация об изменении отбельных байт в файловой системе.

ext3 использует Journaling Block Device layer или JBD – механизм, разработанный независимо для журналирования на любых блоковых устройствах. Этот подход позволяет, например, записывать несколько изменений, внесенных в один блок, с помощью одной операции записи блока на диск. Использование физического журналирования ведет к увеличению размера файла журнала, по сравнению с логическим журналированием, но существенно упрощает его структуру.

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

Существует три режима ведения журнала:

data=writeback             самый простой режим журналирования meta-data. В журнале файлы не хранятся.

data=ordered                формально то же самое, но обеспечивается запись данных до внесения изменений в meta-data. Это гарантирует, например, что данные записанные в конец файла будут всегда записаны корректно (или не записаны совсем). При модификации блоков внутри файла, безусловно, могут быть проблемы. Несколько более медленная работа, чем предыдущий режим, но надежность существенно выше.

data=journal                 при записи данные записываются сначала в журнал, а потом на диск. Это обеспечивает непротиворечивость как data, так и meta-data.

 

 

ext4

Файловая система построена на основе ext3. Впервые патч к ядру Linux с поддержкой этой файловой системой был выпущен 10 октября 2006г. Основной особенностью стало увеличение максимального объема одного раздела диска до 1 эксабайта (260 байт).

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

Появилось понятие delayed allocation – данные на диск записываются не сразу, а только после того, как накопятся в памяти, что позволяет лучшим образом использовать возможности экстентов.

Пропало ограничение на максимально возможное количество подкаталогов одного каталога (ранее 32тыс. или 64 тыс. – в зависимости от опций ядра).

RaiserFS

Очень мощная файловая система, работающая примерно в 10 раз быстрее чем ext2 на операциях с маленькими файлами, и опережающая ext2 почти во всех других операциях. Создана Hans Raiser и его командой. Обычно, под RaiserFS понимается 3-я версия этой файловой системы. 4-ая (последняя) версия, обычно, называется RaiserFS4. В настоящее время разработка RaiserFS прекращена. RaiserFS4 продолжает разрабатываться, несмотря на то, что Ганс Рейзер (создатель данной ФС) был арестован и приговорен с пожизненному заключению.

 

Данные о файлах хранятся не в линейном списке, как в ext2, а в B-дереве. Дисковое пространство под inode выделяется динамически в процессе работы. Данные маленьких файлов могут храниться в самих Inode. Возможен режим работы, когда под хвосты файлов память выделяется отдельно в самой структуре B-дерева, хранящего meta-data.

Под В-деревом подразумевается структура данных, состоящая из узлов. В каждом узле располагается от 1 до n элементов данных и на один больше указатель на дочерний узел. У В-дерева есть корневая вершина, промежуточные узлы и конечные узлы – листья. В-дерево строится так, что длина всех ветвей дерева одинакова. В-Дерево является упорядоченным, в следующем смысле. В каждом узле дерева для каждого элемента данных vi элементы поддерева, на который ссылается i+1 - ый указатель, больше или равны vi , а все элементы поддерева, на который ссылается i - ый указатель, меньше vi . Это гарантирует, что поиск любого элемента дерева происходит за время порядка nlognN операций, где N – количество элементов данных в дереве.

Существуют алгоритмы, позволяющие за время порядка O(log N) производить поиск элемента в дереве, добавление элемента в дерево и удаление элемента из дерева.

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

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

Raiser4

Файловая система, появившаяся в 2006г., написанная Гансом Рейзером и его компанией NameSys. Файловая система написана с нуля, но несет некоторую преемственность по отношению к файловой системе RaiserFS.

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

Плагины задают возможности работы, практически, со всеми объектами файловой системы, поэтому файловая система не имеет определенной зафиксированной структуры. Можно говорить о структуре ФС, предоставляемой изначальным набором плагинов, входящим  в поставку Raiser4. Разработчики называют этот стандарт format40.

Особенностью данной ФС является то, что все элементы данных (кроме суперблока и битовых карт) хранятся в одном B-дереве. Вершинами дерева являются структуры типа znode, хранящие информацию только о самом дереве и указатель на структуру типа jnode, содержащей, собственно, данные, указатель на родителя и братьев узла, указатель на плагин, обрабатывающий данный узел, блокировки и т.д.. Отметим, что наличие блокировок отдельных узлов очень важно. В RaiserFS таких блокировок нет. Перестройка дерева, связанная с модификацией/удалением/добавлением одного узла, может затрагивать некоторое количество блоков всего дерева и весьма нетривиальна. Для корректного выполнения этой процедуры мы должны обеспечивать неизменяемость некоторых узлов дерева в течение выполнения операции. В RaiserFS это приводит к тому, что пока один процесс подготавливает изменения в дереве, другой процесс может дерево существенно изменить и все подготовки первого процесса должны быть игнорированы.

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

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

 

 

UFS1 (FFS)

UFS1 является первой версией FFS (быстрая файловая система), созданной в Беркли. Первая ее версия была созданная в 1984г. с выходом ОС 4.2BSD. Заметим, что ext2 создавалась на основе UFS1. С тех пор система активно развивается. В нее вносилось много нововведений (Sun Microsystems внесла в нее журналирование, независимо, аналогичную работу проделала собственная команда создателей FreeBSD).

Раздел данной ФС содержит:

·        BR размером в 8Kb

·        Суперблок (содержит параметры и статистику ФС)

·        Набор групп цилиндров (Cylinder Groups)

 

Каждая CG содержит копию суперблока, набор i-node, битовую карту блоков и битовую карту i-nodes, некоторую статистику по CG (количество свободных блоков, свободных i-node, размер CG).

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

Каталог представляет собой набор структур каталога. Каждая структура каталога содержит

·        номер i-node

·        длина структуры каталога

·        тип файла

·        длина имени

·        строку имени фиксированной длины

 

UFS2

Основной предпосылкой создания UFS2 стали 32-битные указатели на номера блоков в UFS1. Это ограничило размер ФС до 1-4Тб. Требовался переход на 64-битные указатели. В этом заключается основное изменение. Было решено внести существенные ограничения в поток требуемых усовершенствований, который накопился за 20 лет существования UFS1. В результате, потребовалось переписать только около 10% кода, что дает возможность параллельного внесения изменений в UFS1/UFS2 при их развитии.

Для того, чтобы не уменьшать количество прямых указателей на блоки файла, размер i-node пришлось увеличить с 128b до 256b.

При работе i-node с диска преобразуются к единому для UFS1 и UFS2 формату. Это также дает возможность параллельно развивать обе ФС.

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

Для единообразия, структуру файла каталога менять не стали. Т.е. 32-битные номера i-node остались.

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

Основным новшеством UFS2 стала существенно модифицированная поддержка Extended Arrtibutes – некоторого дополнительного массива данных, вязанного с i-node. В i-node UFS1 хранились два указателя на блоки EA. В UFS2 их количество увеличилось до 5 и приготовлен механизм для хранения массива указателей на блоки EA.

Первым применением EA было расширение политики безопасности, предоставляемой обычной UNIX-файловой системой. Создавался файл ограниченного размера, в котором для каждого i-node отводилась область, содержащая атрибуты специфических прав доступа для различных пользователей. Ограниченность размера этой области создавала ограничение на количество возможных пользователей в системе. Привязка ЕА непосредственно к i-node снимает это ограничение. Кроме того, привязка ЕА к i-node снимает вопрос синхронизации записи данных в файл и в таблицу EA.

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

К числу новшеств, появившихся в UFS2, следует отнести также появление в inode поля с временем создания файла (на самом деле, это поле появилось на месте неиспользуемого поля и размер структуры не изменился) и решение проблемы 2038 (в 2038 г. 32-битной переменной перестанет хватать для хранения времени в секундах, прошедших от начала 1970г; в USF2 под переменную времени отводится 64бита).

 

JFS

JFS была создана в 1990г. вместе с первым релизом AIX. Система была очень сильно привязана к структуре менеджера памяти AIX и абсолютно не поддавалась перенесению в другую среду. В результате большой работы сотрудников IBM система претерпела изменения, в результате которых ее удалось перенести в Linux.

Система отличается очень хорошей проработанностью, оптимизированностью и надежностью, но производительность ее не впечатляет.

Дисковый раздел представляется в ней Логическим томом.

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

Том разбивается на Allocations groups, которые объединяют логически близкие данные. Каждая Allocation group имеет размер, представляющий собой степень двойки. В последней группе непомещающиеся блоки помечаются как занятые.

Каждый файл представляется как группа экстентов. Экстент представляет собой непрерывную последовательность блоков диска длиной от 1 до 224-1. Т.о. экстент описывается номером своего первого блока и его длиной.

Файл представляет собой набор экстентов, хранящихся в B+-дереве.

Каждый файл задается с помощью i-node. i-nodes файлов хранятся  i-node-экстентах, в каждом их которых хранится 32 i-node. Неиспользуемый i-node определяется по количеству ссылок на него, хранящимся в самом i-node (=0).

В конце каждого i-node присутствует область, в которой для маленьких файлов хранятся data файла, а для больших – не более восьми узлов B+-дерева экстентов.

Каталог представляет собой файл, содержащий имена файлов, содержащихся в B+-дереве, отсортированному по имени файла.

 Второй i-node тома содержит B+-дерево блоков диска, содержащих битовую карту, задающую свободные/занятые блоки файловой системы.

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

 

XFS

XFS первоначально была разработана Silicon Graphics, Inc. в начале 90-х годов. Далее (в 1994г.) она была переработана и стала основной файловой системой на всех IRIX-based платформах. Недавно она появилась и на Linux. Она ориентирована на работу с очень большими файлами, и здесь она сильно обгоняет в производительности вышеперечисленные системы. В остальных областях не уступает.

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

Раздел разбивается на 8 или больше allocation groups. В каждой из них существует что-то вроде своей мини-файловой системы. Это очень удобно для распараллеливания. Т.е. с такой системой очень удобной работать на многопроцессорных многозадачных машинах. 

Использует логическое журналирование meta-data. Файл журнала может быть вынесен на отдельный раздел (носитель), что повышает быстродействие. Meta-данные здесь более часто сбрасываются на диск, чем в RaiserFS. Это провоцирует более частое сбрасывание на диск самих данных, что повышает надежность системы.

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

 

DevFS

DevFS является альтернативой стандартному подходу, издавна используемому в UNIX для работы с папкой /dev (см. далее Файлы устройств).

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

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

tmpFS

Это – файловая система на основе виртуальной памяти. Виртуальная память поддерживается ядром системы. tmpFS не требует форматирования. tmpFS имеет динамический объем (размер увеличивается/уменьшается с ростом/уменьшением объема занятого в системе пространства).

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

Отметим, также, что возможна монтировка части одной файловой системы на некоторую папку. Таким образом, например, мы может создать новую папку в уже подмонтированной tmpFS и подмонтировать ее к папке /tmp:

# mkdir /dev/shm/tmp
# chmod 1777 /dev/shm/tmp
# mount --bind /dev/shm/tmp /tmp

 

NFS

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

 

 

 

Понятие монтировки.

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

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

    mount                                                                      распечатать список всех монтировок

       mount -a [-fFnrsvw] [-t vfstype]                          -a = монтировать все ф.с. из /etc/f stab

       mount [-fnrsvw] [-o options [,...]] device | dir                 задается только имя устройства или папки, а недостающие данные (например, для папки – имя устройства, или для устройства – имя папки) берутся из файла /etc/fstab

       mount [-fnrsvw] [-t vfstype] [-o options] device dir        полный синтаксис

 

Отдельно стоит сказать о монтировке по протоколу NFS. Данный протокол позволяет монтировать файловые системы с удаленных компьютеров. В качестве имени устройства указывается адрес сервера и имя папки на сервере, с которого монтируется файловая система:

mount –t nfs  192.192.192.192:/var/www/dir  /mnt/dir

 

В свою очередь, сервер должен разрешить данному клиенту понтировать его файловые системы. В ОС Linux, AIX это делается с помощью соответствующих записей в файле /etc/exports. В простейшем случае в отдельной строке этого файла можно указать имя папки, которую все смогут монтировать по протоколу NFS. Можно указывать ограничения на список клиентов, которые имеют право монтировки каждой папки. Пример файла /etc/exports:

 

/               master(rw) trusty(rw,no-root-squash)

/projects       proj*.local.domain(rw)

/usr            *.local.domain(ro) @trusted(rw)

/var/www/joe       pc001(rw,all-squash,anonuid=150,anongid=100)

/pub            (ro,insecure,all-squash)

/pub/private    (noaccess)

 

В ОС Solaris разрешения организуются командой share . Например:

share -F nfs -o ro /disk

 

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

На данный момент в различных версиях Linux широко используются программы, обеспечивающие автомонтировку сменных устройств (например, система hal, запускаемая демоном hald).

Загрузка UNIX. Завершение работы

Загрузку UNIX можно рассмотреть на примере Linux. В остальных разновидностях она происходит аналогично, с точностью до имен используемых папок.

Код BR инициализирует распаковку ядра Linux и начало его выполнения.

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

Монтировка файловых систем осуществляется следующим образом: сначала монтируется корневая файловая система (ее расположение задается в самом ядре или в его параметрах), далее рассматривается файл /etc/fstabSolaris, например, этот файл зовется /etc/vfstab, AIX - /etc/filesystems). Каждая строка этого файла описывает одну файловую систему. Так, например, в Linux каждая строка выглядит следующим образом:

/dev/fd0       /mnt/dos-floppy    msdos   noauto,user 0 0

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

Существует несколько уровней загрузки, обозначающихся номерами (обычно от 0 до 6). Выйти на соответствующий уровень можно командой /sbin/init n, где n - уровень загрузки. Обычно, стандартный уровень загрузки имеет уровень 3. В Linux в папке /etc/rc.d. В ней для каждого уровня загрузки существует своя папка с именами rc0.d, rc1.d, и т.д. В каждой папке лежат выполняемые файлы, которые должны выполниться в начале данного уровня загрузки. Программа init запускает программу getty, которая, собственно, и обеспечивает создание текстового терминала и задание его свойств.  Эта процедура также запрашивает имя пользователя для передачи его процедуре login . Последняя процедура, если необходимо, запрашивает пароль пользователя и, в случае успешной идентификации пользователя, после установки различных параметров вызывается login shell – исходный интерпретатор командной строки.

 

Завершение работы используются процедуры

sync                   синхронизация памяти с диском

halt                    немедленное завершение работы системы (реально, часто = shutdown). В Linux = init 0

reboot                инициализация процесса перезагрузки. В Linux = init 6

shutdown          инициализация процесса завершения работы системы. Ключи:

   -t sec    начать процесс через sec секунд

   now     сейчас

   -r         = reboot

   -h         = halt