СИСТЕМНЫЕ ОПЕРАЦИИ ДЛЯ РАБОТЫ С ФАЙЛОВОЙ СИСТЕМОЙ

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

Файловая подсистема — обеспечивает унифицированный интерфейс доступа к данным, расположенным на дисковых накопителях, и к периферийным устройствам. Одни и те же функции ореn, read, write, могут использоваться как при чтении или записи данных на диск, так и при выводе текста на принтер или терминал.

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

Файловая подсистема — обеспечивает перенаправление запросов, адресованных периферийным устройствам, соответствующим модулям подсистемы ввода/вывода

Основополагающие реализации UNIX:

SVR4 — System V Releas 4 (Novel 1990) SVR{1983..1990}

4xBSD — Berkeley Software Distribution 4xBSD{1980..1994}

Mach — https://ru.wikipedia.org/wiki/Mach Mach.x{1985..1994}

Базовая файловая система System V

Каждый жесткий диск состоит из одной или нескольких логических частей, называемых разделами (partitions). Расположение и размер раздела определяются при форматировании диска. В UNIX разделы выступают в качестве независимых устройств, доступ к которым осуществляется как к различным носителям данных. Например, диск может состоять из четырех разделов, каждый из которых содержит свою файловую систему. Заметим, что в разделе может располагаться только одна файловая система, которая не может занимать несколько разделов. В другой конфигурации диск может состоять только из одного раздела, позволяя создание весьма емких файловых систем.

Суперблок (superblocк). Содержит общую информацию о файловой системе, например, об ее архитектуре, общем числе блоков и индексных дескрипторов, или метаданных (inode).

Массив индексных дескрипторов (ilist). Содержит метаданные всех файлов файловой системы. Индексный дескриптор содержит статусную информацию о файле и указывает на расположение данных этого файла. Ядро обращается к inode по индексу в массиве ilist. Один inode является корневым (root) inode файловой системы, через него обеспечивается доступ к структуре каталогов и файлов после монтирования файловой системы. Размер массива ilist является фиксированным и задается при создании файловой системы. Таким образом, файловая система s5fs имеет ограничение по числу файлов, которые могут храниться в ней, независимо от размера этих файлов.

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

Пример индексного узла с прямой, двойной и тройной адресацией:

Поле di_mode хранит несколько атрибутов файла:тип файла (IFREG для обычных файлов, IFDIR для каталогов, IFBLK или IFCHR для специальных файлов блочных и символьных устройств соответственно), права доступа к файлу для трех классов пользователей и дополнительные атрибуты выполнения (SUID, SGID и sticky bit)

В индексном дескрипторе отсутствует информация о времени создания файла. Вместо этого inode хранит три значения времени:

• время последнего доступа (di_atime)

• время последней модификации содержимого файла (di_mtime)

• время последней модификации метаданных файла (di_ctime)

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

Массив (некоторое количество записей) имеет фиксированный размер и состоит из 13 элементов.

(128 байт в UFS(Unix File System), 256 в UFS2- 64-разрядная версия) Каждая запись однозначно соответствует одному файлу, как реально существующему, так и только могущему быть созданным. При этом первые 10 элементов адресуют непосредственно блоки хранения данных файла. Одиннадцатый элемент адресует блок, в свою очередь содержащий адреса блоков хранения данных. Двенадцатый элемент указывает на дисковый блок, также хранящий адреса блоков, каждый из который адресует блок хранения данных файла. Тринадцатый элемент используется для тройной косвенной адресации, когда для нахождения адреса блока хранения данных файла используются три дополнительных блока.

Такой подход позволяет при относительно небольшом фиксированном размере индексного дескриптора поддерживать работу с файлами, размер которых может изменяться от нескольких байтов до десятка мегабайтов. Для относительно небольших файлов (до 10 Кбайт при размере блока 1024 байтов) используется прямая индексация, обеспечивающая максимальную производительность. Для файлов, размер которых не превышает 266 Кбайт (10 Кбайт + 256x1024), достаточно простой косвенной адресации. Наконец, при использовании тройной косвенной адресации можно обеспечить доступ к 16777216 блокам (256 x 256 x 256).

Файлы в UNIX могут содержать так называемые дыры. Например, процесс может создать пустой файл, с помощью системного вызова lseek сместить файловый указатель относительно начала файла и записать данные. При этом между началом файла и началом записанных данных образуется дыра — незаполненная область. При чтении этой области процесс получит обнуленные байты. Поскольку логические блоки, соответствующие дыре, не содержат данные, не имеет смысла размещать для них дисковые блоки. В этом случае соответствующие элементы массива адресов inode содержат нулевой указатель. Когда процесс производит чтение такого блока, ядро возвращает последовательность нулей. Дисковые блоки размещаются только при записи в соответствующие логические блоки файла.

Множество программ, в (ОС) UNIX, часто используют номера индексных дескрипторов для обозначения файлов. Популярная встроенная программа проверки жестких дисков fsck - дефолт в BSD, или команда pfiles могут послужить в данном случае примерами, так как у них есть необходимость естественным образом конвертировать номера индексных дескрипторов в пути файлов и обратно. Это может быть дополнено использованием программы поиска файлов find с ключом -inum или командой ls с соответствующим ключом (которым на большинстве платформ является -i).

Иноды могут 'закончиться'. В этом случае нельзя записать информацию на устройство, даже если там достаточно свободного места. (Стандартно, очень много мелких файлов..??? Надо подчистить....Проверить каталог /var/spool/clientmqueue)

od (octal dump – восьмеричный дамп) hd (hex dump - шестнадцатиричный дaмп)

http://docs.kpda.ru/index/octal dump http://citforum.ru/operating_systems/manpages/OD

http://docs.kpda.ru/index/hex dump http://bsdadmin.ru/mans-freebsd/ASII-dump-HD/

https://drive.google.com/file OD=sharing <<------------- примеры OD PDF

od — общепринятая утилита отладки, в данном случае будет удобно при помощи ее взглянуть на внутренность файла с точки зрения системы, однако если проводить эти "эксперименты" на Linux, то в силу новизны используемых файловых систем (ext2-3-4) это не s5fs или организации системных вызовов, утилита не покажет нам дамп каталога, что будет важно для понимания системного и читабельного имени файла, поэтому будем использовать BSD где то же однако не явно (если это не s5fs) но можно продемонстрировать связь inode-ов с именем файла по средствам восьмиричного-шеснадцатиричного дампа (о чем ниже) , реализации файловых систем современных версий отошли от записей фиксированной длины (в них формат файла каталога более сложный) и не ограничивают длину имени файла 14-ю символами, как это было когда то, FFS (Fast File System), появившаяся впервые в BSD 4.2, допускает уже 255-символьные имена файлов. Команда od без параметров выводит дамп файла 16-битными порциями или 2-байтовыми словами.

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

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

$ od -cx

od test chek tab

0000000 o d t e s t c h e k \t t a b

646f 7420 7365 2074 6863 6b65 7409 6261

^C

$

В общем виде формат запуска утилиты можно представить так: (параметры в скобках не обязательны)

od [- опции] [-A в каком формате будет колонка позиций ] [-j начать с какого байта ] [-N длина ] [-t формат вывода ] [файл]

http://pubs.opengroup.org/onlinepubs http://www.thegeekstuff.com https://www.opennet.ru/MAN

Синтаксис: od [-bcdox] [файл]

Описание: Вывод содержимого файла в указанном формате.

Опции, коротко:

В примере выше: параметр c - «интерпретировать байты как символы». Если задан параметр b, то будет показано и восьмеричное представление байтов.

Семизначные числа слева обозначают местоположение в файле – порядковый номер следующего выведенного символа, в восьмеричной записи. Шестнадцатеричная запись – параметр x, после каждой строки встречается символ с восьмеричным значением 012. Это ASCII символ новой строки, то есть то, что система помещает в поток ввода, когда пользователь нажимает клавишу Return. По соглашению, заимствованному из Си, представление символа новой строки выглядит как \n, но это просто условность, используемая такими программами, как od, для удобства чтения, на самом же деле величина, хранимая в файле, – это один байт 012.

Символ новой строки – это наиболее часто употребляемый специальный символ. Другие символы, сопоставленные некоторым операциям управления терминалом, включают в себя возврат на одну позицию (восьмеричное значение 010, выводится как \b), табуляцию (011, \t) и возврат каретки (015,\r). Важно различать значение, сохраняемое для символа в файле, и то, как он интерпретируется в различных ситуациях. Например, когда с клавиатуры вводится возврат на одну позицию (Backspace), если этот символ в конкретной системе служит для удаления, ядро интерпретирует его как отказ от предыдущего введенного символа. В итоге и символ возврата, и символ, стоявший перед ним, исчезают, но введение возврата на одну позицию отражается на терминале, курсор перемещается на одну позицию назад........

(Опция -A команды cat также позволяет увидеть, где расположены символы табуляции и конца строки)

Керниган, Пайк - UNIX. Программное окружение <<------(ст 62) PDF

hex редакторы <<-------- https://traditio.wiki https://ru.wikipedia.org/wiki/Hex

Имена файлов

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

Каталог файловой системы s5fs представляет собой таблицу, каждый элемент которой имеет фиксированный размер в 16 байтов: 2 байта хранят номер индексного дескриптора файла, а 14 байтов — его имя. Это накладывает ограничение на число inode, которое не может превышать 65 535. Также ограничена и длина имени файла: его максимальный размер — 14 символов. Структура каталога приведена на рисунке ниже. Первые два элемента каталога адресуют сам каталог (текущий каталог) под именем ''.''и родительский каталог под именем ''..''.

При удалении имени файла из каталога (например, с помощью команды rm), номер inode соответствующего элемента устанавливается равным Ø. Ядро обычно не удаляет такие свободные элементы, поэтому размер каталога не уменьшается даже при удалении файлов. Это является потенциальной проблемой для каталогов, в которые временно было помещено большое количество файлов. После удаления большинства из них размер каталога останется достаточно большим, поскольку записи удаленных файлов будут по-прежнему существовать. Иллюстрацию этого явления в SCO UNIX можно привести, применив команду hd (manpages/HD ), обеспечивающую вывод неинтерпретированного содержимого файла (шестнадцатеричный дамп). (hexdump)

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

http://mf.grsu.by/UchProc/livak/b_org/hard.htm <<<------- Физическая структура жестких дисков

В версии 4.3BSD UNIX были внесены существенные улучшения в архитектуру файловой системы, повышающие как ее производительность, так и надежность. Новая файловая система получила название Berkeley Fast File System (FFS) UNIX File System (UFS)

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

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

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

Организация файловой системы предусматривает логическое деление дискового раздела на одну или несколько групп цилиндров (cylinder group).

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

Эти группы цилиндров состоят из:

Резервное копирование суперблока

Заголовок группы цилиндров, с информацией о группе цилиндров, аналогично суперблоку

Количество дескрипторов в группе цилиндров

Количество блоков данных в группе цилиндров

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

Группа управляет данными цилиндра, хранящиеся в блоках, содержащихся группами цилиндров.

http://www.linux.org/threads/unix-file-system-ufs.

Производительность файловой системы существенным образом зависит от размера блока хранения данных. Чем больше размер блока, тем большее количество данных может быть прочитано без поиска и перемещения дисковой головки. Файловая система FFS поддерживает размер блока до 64 Кбайт. Проблема заключается в том, что типичная файловая система UNIX состоит из значительного числа файлов небольшого размера. Это приводит к тому, что частично занятые блоки используются неэффективно, что может привести к потере до 60% полезной емкости диска.

Этот недостаток был преодолен с помощью возможности фрагментации блока. Каждый блок может быть разбит на два, четыре или восемь фрагментов. В то время как блок является единицей передачи данных в операциях ввода/вывода, фрагмент определяет адресуемую единицу хранения данных на диске. Таким образом был найден компромисс между производительностью ввода/вывода и эффективностью хранения данных. Размер фрагмента задается при создании файловой системы, его максимальное значение определяется размером блока (0,5 размера блока), а минимальный — физическими ограничениями дискового устройства, а именно: минимальной единицей адресации диска — сектором.

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

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

В отличие от s5fs, файловая система FFS при размещении блоков использует стратегию,

направленную на увеличение производительности. Некоторые из принципов приведены ниже:

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

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

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

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

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

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

Каталоги

Брайан Керниган, Деннис Ритчи <<-------- ст. 170 Печать каталогов

Для начала возможно следует вспомнить, что каталог есть файл содержащий список файлов, и к слову пользователи не "замысловатые" (пользователи рожденные до Mach) вспоминая, что UNIX - все файлы, делят файлы на две группы - каталоги и прочие файлы. Предназначение каталогов — единственное, и ритуально важное: быть хранителями имен входящих в них файлов, которым однозначно поставлены в соответствие идентификаторы inodes, хранящих метаданные этих файлов, что бы явно проиллюстрировать этот факт воспользуемся выше упомянутыми утилитами отладки и вывода дампа файла - od и hd:

Если кратко то так:

# hd -x .

00000000 e2 85 11 00 0c 00 04 01 2e 00 00 00 1e 57 0b 00 |.............W..|

0000000 85e2 0011 000c 0104 002e 0000 571e 000b

00000010 0c 00 04 02 2e 2e 00 00 e3 85 11 00 10 00 08 05 |................|

0000010 000c 0204 2e2e 0000 85e3 0011 0010 0508

00000020 66 69 6c 65 31 00 ff ff e4 85 11 00 10 00 08 05 |file1...........|

0000020 6966 656c 0031 ffff 85e4 0011 0010 0508

00000030 66 69 6c 65 32 00 ff ff e5 85 11 00 c8 01 08 05 |file2...........|

0000030 6966 656c 0032 ffff 85e5 0011 01c8 0508

00000040 66 69 6c 65 33 00 ff ff 00 00 00 00 00 00 00 00 |file3...........|

0000040 6966 656c 0033 ffff 0000 0000 0000 0000

00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

0000050 0000 0000 0000 0000 0000 0000 0000 0000

*

0000200

#

============= /usr/include/sys/dirent.h:

struct dirent {

__uint32_t d_fileno; /* file number of entry */

__uint16_t d_reclen; /* length of this record */

__uint8_t d_type; /* file type, see below */

__uint8_t d_namlen; /* length of string in d_name */

#if __BSD_VISIBLE

#define MAXNAMLEN 255

char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */

#else

char d_name[255 + 1]; /* name must be no longer than this */

#endif

};

==============================================================================================

d_fileno (1148387)

/ ,--------- d_reclen (16)

/ / ,----- d_type (8 = DT_REG)

/ / / ,--- d_namlen (5)

vvvvvvvvvvv vvvvv vv vv

00000010 0c 00 04 02 2e 2e 00 00 e3 85 11 00 10 00 08 05 |.................|

00000020 66 69 6c 65 31 00 ff ff e4 85 11 00 10 00 08 05 |file1...........|

^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^

\ \-------------------------------- padding

\------------------------------------------- d_name

==============================================================================================

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

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

После этого вызывается операция vfs_mount , соответствующая данному типу файловой системы. Конкретные действия определяются реализацией файловой системы и могут существенно различаться. Например, операция монтирования локальной файловой системы ufs предусматривает считывание в память метаданных системы, таких как суперблок, в то время как монтирование удаленной NFS файловой системы включает передачу сетевого запроса файловому серверу. Однако монтирование предусматривает выполнение и ряда общих операций, включающих:

— проверку соответствующих прав на выполнение монтирования;

— размещение и инициализацию специфических для файловой системы данного типа данных, сохранение адреса этих данных в поле vfs_data элемента vfs;

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

Говоря формально, полное имя файла представляет собой последовательность слов, разделенных символом '/'. Каждый компонент имени, кроме последнего, является именем каталога. Последний компонент определяет собственно имя файла. При этом полное имя может быть абсолютным или относительным. Если полное имя начинается с символа '/', представляющего корневой каталог общего логического дерева файловой системы, то оно является абсолютным, однозначно определяющим файл из любого места файловой системы. В противном случае, имя является относительным и адресует файл относительно текущего каталога. Примером относительного имени может служить include/sys/user.h, а абсолютное имя этого файла — /usr/include/sys/user.h. Как следует из этих рассуждений, два каталога играют ключевую роль при трансляции имени: корневой каталог и текущий каталог. Каждый процесс адресует эти каталоги двумя полями структуры u_area:

struct vnode *u_cdir Указатель на vnode текущего каталога

struct vnode *u_rdir Указатель на vnode корневого каталога

В зависимости от имени файла трансляция начинается с vnode, адресованного либо полем u_cdir, либо u_rdir. Трансляция имени осуществляется по компонентно, при этом для vnode текущего каталога вызывается соответствующая ему операция vn_lookup (), в качестве аргумента которой передается имя следующего компонента. В результате операции возвращается vnode, соответствующий искомому компоненту.

Если для vnode каталога установлен указатель vn_vf smountedhere, то данный каталог является точкой монтирования. Если имя файла требует дальнейшего спуска по дереву файловой системы (т. е. пересечения точки монтирования), то операция vn_lookup() следует указателю vn_vfsmountedhere для перехода в подключенную файловую систему и вызывает для нее операцию vfs_root () для получения ее корневого vnode. Трансляция имени затем продолжается с этого места.

Пересечение границы файловых систем возможно и при восхождении по дереву, например, если имя файла задано указанием родительского каталога — ../../myfile.txt. Если при движении в этом направлении по пути встречается корневой vnode подключенной файловой системы (установлен флаг VR00T в поле v_flag), то операция vn_lookup следует указателю vfs_vnodecovered, расположенному в записи vfs этой файловой системы. При этом происходит пересечение границы файловых систем, и дальнейшая трансляция продолжается с точки монтирования.

Если искомый файл является символической связью, и системный вызов, от имени которого происходит трансляция имени, "следует" символической связи, операция vn_lookup вызывает vn_readlink для получения имени целевого файла. Если оно является абсолютным (т. е. начинается с "/"), то трансляция начинается с vnode корневого каталога, адресованного полем u_rdir области u-area.

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

Файловый дескриптор, используемый для доступа процесса к файлу, является индексом таблицы файловых дескрипторов (file descriptor table). Каждый процесс имеет собственную таблицу файловых дескрипторов, которая расположена в его u-area. На рисунке выше показаны два процесса, каждый из которых использует собственную таблицу файловых дескрипторов.

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

Как следует из описания поля l_type структуры flock, существуют два типа блокирования записи: для чтения (F_ RDLCK) и для записи (F_WRLCK). Правила блокирования таковы, что может быть установлено несколько блокирований для чтения на конкретный байт файла, при этом в установке блокирования для записи на этот байт будет отказано. Напротив, блокирование для записи на конкретный байт должно быть единственным, при этом в установке блокирования для чтения будет отказано.

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

struct flock lock;

/‘Заполним описание lock с целью блокирования всего файла для записи*/

lock.l_type = F__WRLCK;

lock.l_st.art = О;

lock.whence = SEEK_SET;

lock.len = 0;

/*Заблокируем файл. Если блокирования, препятствующие данной операции, уже существуют — ждем их снятия*/

fcntl(fd, SETLKW, Slock);

/‘Запишем данные в файл — нам никто не помешает*/

write(fd, record, sizeof(record));

/*Снимем блокирование*/

lock.l_type = F_UNLCK;

fcntl(fd, SETLKW, Slock);

В отличие от рекомендательного в UNIX существует обязательное блокирование (mandatory lock), при котором ограничение на доступ к записям файла накладывается самим ядром. Реализация обязательных блокировок может быть различной. Например, в SCO UNIX(SVR3) снятие бита х для группы и установка бита SGID для группы приводит к тому, что блокировки, установленные fcntl или lockf, станут обязательными. UNIX SVR4 поддерживает установку блокирования отдельно для записи и для чтения, обеспечивая тем самым доступ для чтения многим, а для записи — только одному процессу. Эти установки также осуществляются с помощью системного вызова fcntl. Следует иметь в виду, что использование обязательного блокирования таит потенциальную опасность. Например, если процесс блокирует доступ к жизненно важному системному файлу и по каким-либо причинам теряет контроль, это может привести к аварийному останову операционной системы.

Внутренняя структура буферного кэша

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

Основные поля структуры buf :

Поле b_flags хранит различные флаги связанного с заголовком буфера. Часть флагов используется буферным кэшем, а часть — драйвером устройства. Например, с помощью флага B_BUSY осуществляется синхронизация доступа к буферу. Флаг B_DELWRI отмечает буфер как модифицированный, или "грязный", требующий сохранения на диске перед повторным использованием. Флаги B READ, B WRITE, B_ASYNC, B DONE И BERROR ИСПОЛЬзуются драйвером диска. Более подробно операция ввода/вывода для драйвера будет рассмотрена в следующей главе.

Буферный кэш использует механизм отложенной записи (write-behind), при котором модификация буфера не вызывает немедленной записи на диск. Такие буферы отмечаются как "грязные", а синхронизация их содержимого с дисковыми данными происходит через определенные промежутки времени. Примерно одна треть операций дискового ввода/вывода приходится на запись, причем один и тот же буфер может на протяжении ограниченного промежутка времени модифицироваться несколько раз. Поэтому буферный кэш позволяет значительно уменьшить интенсивность записи на диск4 и реорганизовать последовательность записи отдельных буферов для повышения производительности ввода/вывода (например, уменьшая время поиска, группируя запись соседних дисковых блоков). Однако этот механизм имеет свои недостатки, поскольку может привести к нарушению целостности файловой системы в случае неожиданного останова или сбоя операционной системы.

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

Для уменьшения вероятности таких потерь в UNIX имеется несколько возможностей:

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

##Во-вторых, процесс может открыть файл в синхронном режиме (указав флаг о sync в системном вызове ореn). При этом все изменения в файле будут немедленно сохраняться на диске.

##Наконец, через регулярные промежутки времени в системе пробуждается специальный системный процесс — диспетчер буферного кэша (в различных версиях UNIX его названия отличаются, чаще всего используется fsflush или bdflush). Этот процесс освобождает

В распоряжении администратора имеется командный интерфейс к системному вызову — утилита sync(lM). Поскольку выполнение команды еще не свидетельствует о фактическом завершении ввода/вывода, администраторы практикуют вызов sync( 1М) несколько раз. Повторные вызовы повышают вероятность того, что ввод/вывод будет завершен прежде, чем будет введена другая команда или остановлена система, поскольку набор команды занимает определенное время. Тот же эффект может быть достигнут просто ожиданием нескольких секунд после ввода sync( 1М), но набор команды позволяет "скрасить ожидание".

"грязные" буферы, сохраняя их содержимое в соответствующих дисковых блоках6 (рис. 4.14, д).

Кэширование в SVR4

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

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

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

fsck [options] filesystem где filesystem — специальный файл устройства, на котором находится файловая система.

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

=======================================

Дамп памяти (англ. memory dump; в Unix — core dump) — содержимое рабочей памяти одного процесса, ядра или всей операционной системы. Также может включать дополнительную информацию о состоянии программы или системы, например значения регистров процессора и содержимое стека. Многие операционные системы позволяют сохранять дамп памяти для отладки программы. Как правило, дамп памяти процесса сохраняется автоматически, когда процесс завершается из-за критической ошибки (например, из-за ошибки сегментации). Дамп также можно сохранить вручную через отладчик или любую другую специальную программу.

-----------------

https://www.esetnod32.ru/support

http://support.kaspersky.ru/general/dumps

-----------------

=======================================