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

Система Linux поддерживает 7 типов файлов:

d - директория

-обычный файл (регулярный файл)

l - soft link

p - именованные программные каналы

s - сокет

c - специальный файл символьного устройства

b - бинарный файл блочного устройства

Файл - это некоторая поименованная свокупность данных. Содержится во вторичной памяти, такой как flash, жесткие диски и прочее. На дисках файлы.

Зачем именуют? Зачем это вообще нужно? Именнованые? Чтобы можно было получить к ней доступ. Организация доступа к файлам данных на диске - файловая система. Нет доступа без имени. Файл всегда имеет имя!

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

Файловая система имеет иерархическую структуру!

Файлы находятся на диске, диск - это физический уровень. На самом верхнем уровне символьный уровень.

1. Символьный уровень.

Файлы именуются символьными структурами. Это весьма удобно, ведь для пользователя вполне логично использовать строки как названия файлов. К слову о ОС. В Unix все файл. Директория тоже файл. Устройства тоже. Это было сделано, чтобы не создавать специальные системные вызовы. Мы пользуемся только open(), read(), write() и может быть close(). (Потом добавила что close в системных вызовах нет)

Это уровень именования файлов. Сюда входит организация каталогов, подкаталогов.

Windows, UNIX/Linux - все эти семейства имеют иерархическую организацию каталогов, так называемое дерево каталогов.

В UNIX/Linux имя файла не является его идентификатором- один и тот же файл может иметь много имен, как мы это заметили еще на прошлых лабах по hardlink. Делалось это для того чтобы к одному и тому же файлу можно было получать доступ из разных директорий, но сейчас часто используется понятие папка.

Вот тут вот была какая-то отсылка к тому, что папка в Windows тоже ничто иное, как link. Эта концепция не особо афишировалась от Microsoft, было создано для пользователя, чтобы было удобно. Папочки, все красиво.

2. Базовый уровень.

Как мы знаем, ссылаться на файл по имени - ну такое. Имя файла не является индентификатором. Тогда как?

Ответ: В файловой системе файлы имеют inode - он же Index Node. Это название исторически сложилось и потом название фактически дескриптора файла не менялось. inode - это ничто иное, как структура ядра.

В ядре существует два типа inode:

• Дисковый inode
• Ядреный inode

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

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

Существует два типа inode так как:

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

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

Сегодня мы знаем, что Windows поддерживает большие файлы. Но эту фишку еще сделали давно в Unix. Данная опция была доступна изначально. Опять же - структура inode используется для адресации.

В inode ядра такая информация не нужна, но нужна информация, которая обеспечивает нахождение файла, принадлежность к файловой системе (далее ФС), к каталогам и подкаталогам.

3. Уровень проверки прав доступа к файлам. Защита информации.

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

Да, это команда chmod

И помни! Не используй в продакшене на бекэнде команду sudo chmod 777 filename !

Если тебе есть что вспомнить - chmod тык

4. Логический уровень

Файлы бывают двух типов в Си - текстовые/символьные(так как тип char занимает 1 байт) и бинарные.

Операционная система поддерживает два типа файлов - байториентированные(В СИ симольные/текстовые) и блокориентированные.

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

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

Блочные файлы называются так из-за того что информация в них записывается блоками равного размера. Из-за такой организации мы имеем произвольный доступ(обратиться к конкретному блоку используя функцию fseek). Если вы все-таки делали лабу по Си с открытием файлов в данном доступе, то помните, что мы делали сортировки. Блочные файлы поддаются сортировке, что очень удобно.

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

---

Система освобождает программиста от необходимости знать нижний уровень (в какой сектор обращаться и тд).

Если речь идёт о внешних запоминающих устройствах, то речь идёт об обычных (регулярных) файлах. Директория тоже рассматривается как файл. Она так же имеет inode. Так же как и pipe ( программный канал ), softlink. Все системой рассматривается как файлы, соответственно информация о них тоже хранится на диске.

Файловая система - это часть ОС, которая отвечает за возможность длительного хранения информации и доступа к ней.

Доступ - создание, чтение, запись, именование, переименование, установка прав, удаление.

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

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

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

а) определяет формат сохраняемой информации и способ её физического хранения;

б) связывает физический носитель информации и системные вызовы (или API) для доступа к файлам. (open, read, write, fopen, fprintf, scanf, rename, remove, cd, так же было сказано про touch, но Рязанова сказала, что не знает такой команды)

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

Поэтому можно сказать

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

Задачи файловой системы:

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

---

4. Логический уровень (продолжение)

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

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

Системы Windows и Unix/Linux поддерживают два типа файлов байториентированные и блокориентированные файлы. Это вытекает из существования двух типов внешних устройств: символьных и блочных. (В настоящее время появились еще сетевые устройства)

5. Физический уровень. Жесткий диск.

Физический уровень - уровень хранения и доступа к данным.

Организация жёсткого диска

Немного о строении жесткого диска. Жесткий диск состоит из одной и более пластины. Вот схематическое представление Рязановой:

(фото с доски)

Как на самом деле выглядит жесткий диск. Изнутри, так сказать(Рязанова не давала).

А вот так вот выглядит разбиение блина - пластины:

(фото с доски)

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

Да и я собственно. Учитывая тот факт, что сектор - ничто иное, как наименьший участок дорожки, зависящий от контроллера самого жесткого диска. Он вроде даже величиной 512 байт. Ну это по состоянию на 2010 год из книги CompTIA A+ Чарльза Брукса. Кому и как верить - без понятия.)_

Танненбаум вообще говорит, что дорожкой называется круговая последовательность битов, записанных на диск за его полный оборот. Каждая дорожка делится на секторы фиксированной длины. Каждый сектор ОБЫЧНО содержит 512 байт данных. Перед данными располагается преамбула, которая позволяет головке синхронизироваться перед чтением и записью... Так же стоит понимать некоторый момент, что от центра к внешним дорожкам количество пространства для записи увеличивается. Очевидно, что такой рисунок, как у Рязановой - неправильный. На самом деле цилиндры делятся на зоны так, чтобы при продвижении от центра диска число секторов увеличивалось. Такой подход правильный, так как удовлетворяет условию, что секторы фиксированного размера. Почему так все работает? У жесткого диска есть контроллер, с которым мы будем видимо общаться. Мы ему именно и кидаем такие команды как READ, WRITE, FORMAT, управление перемещением считывающих головок, поиска ошибок и прочего...

Блок - наименьшая адресуемая порция данных к которой можно обратится на жестком диске.

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

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

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

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

---

VFS - виртуальная файловая система

Для файловой системы Unix/Linux характерна поддержка большого числа разных файловых систем. Это возможно в системе благодаря наличию интерфейса который в Linux называется просто VFS, В Unix называется VFS/VNODE. В операционных системах больше всего отличий наблюдается именно в файловых подсистемах. Как мы видим, файловая подсистема Linux отказалась от понятия VNODE (virtual node), но и в той и в другой системе остаётся inode - дескриптор конкретного файла.

Виртуальная файловая система - набор структур(с точки зрения реализации). Базовыми являются всего 4 структуры.

Базовые структуры VFS:

 1. Суперблок (struct superblock)

 2. Индексный узел (struct inode)

 3. Элемент каталога (struct dentry) (dentry - сокращение от directory entry)

 4. Файл (struct file)

Вот такая картинка была представлена

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

Общее для разных ФС:

• Поддержка таких понятий как:

  • файлы

  • каталоги

• Поддержка таких действий, определённых на файлах, как:

  • создание

  • удаление

  • переименование

  • закрытие

  • открытие

В результате в Unix/Linux сформирован абстрактный интерфейс VFS, который является ожидаемым конкретными ФС. В результате соответствующие действия конкретной файловой системы отображаются на действия виртуальной файловой системы. В основе этого лежат соответствующие структуры, которые позволяют операционным системам Unix/Linux работать с большим количеством файловых систем. (NTFS, FAT, FAT32)

Тут была обрисована картинка.

Приложение выполняет системный вызов write()-> Этот системный вызов будет преобразован в sys_write (при помощи VFS) -> этот системный вызов будет преобразован в некоторый метод записи файловой системы -> в итоге информация будет записана на физический носитель.

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

Рассмотрим схему архитектуры файловой системы:

Верхние два элемента - пользовательский уровень, а все последующие - уровень ядра

Приложение может использовать функции glibc - библиотека GNU C или же напрямую системные вызовы ядра. Первые, очевидно, удобнее. Но вызывая системные вызовы, такие как open(), read(), write(), close() - можно немного повысить производительность приложения.

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