Что будет в этой статье
Продолжаем серию статей по созданию файловой системы в ядре Linux на основе материалов курса ОС в Академический университет .
В последний раз Мы настроили среду, которая нам понадобится для знакомства с ядром.
Затем мы взглянули на загружаемые модули ядра и написали простое «Hello, World!» И наконец, мы написали простую и бесполезную файловую систему.
Пришло время продолжить.
Основная цель этой статьи — научить файловую систему читать с диска.
На данный момент он будет читать только служебную информацию (суперблок и индексные дескрипторы), поэтому его все еще довольно сложно использовать.
Почему так мало? Дело в том, что в этом посте нам нужно будет определить структуру нашей файловой системы — как она будет храниться на диске.
Кроме того, мы встретим пару интересных моментов, таких как SLAB и RCU. Все это потребует некоторых пояснений — много слов и мало кода, поэтому пост уже будет достаточно длинным.
Скучное начало
Наша файловая система должна быть простой, поэтому храниться на диске она будет просто:
Начнем с конца:
- блоки данных – блоки полезных данных, т.е.
содержимого файлов и папок;
- таблица инодов — таблица инодов; количество узлов индекса определяется при форматировании и сохраняется в виде непрерывной последовательности блоков;
- свободные иноды — битовая карта свободных/занятых инодов, занимающая ровно 1 блок;
- свободные блоки — растровое изображение свободных/занятых блоков, также занимает 1 блок;
- суперблок — очевидно суперблок нашей файловой системы; он хранит размер блока, количество блоков в таблице индексных дескрипторов, номер индексного дескриптора корневой папки;
Например, группа блоков ext2/3 имеет аналогичную структуру, только ext2/3 работает с несколькими такими группами, и мы ограничимся одной.
Этот формат считается устаревшим, и от него отходят новые файловые системы.
Например, btrfs использует более интересный диаграмма , что обеспечивает ряд преимуществ перед семейством ext. Но вернемся к нашим овцам.
Мы определили, что растровые изображения суперблока и блока/инода занимают первые три блока файловой системы, но сколько занимает таблица индексных дескрипторов? Вообще говоря, фиксировать это значение некорректно; это сильно зависит от того, как будет использоваться файловая система.
Например, если вы планируете хранить в основном большие файлы, имеет смысл уменьшить эту таблицу, поскольку маловероятно, что у вас закончатся индексные дескрипторы раньше, чем закончится дисковое пространство.
С другой стороны, если вы собираетесь хранить много небольших файлов, есть вероятность, что у вас закончатся индексные дескрипторы раньше, чем закончится дисковое пространство, если таблица слишком мала.
Утилита mke2fs, которая используется для форматирования диска под файловые системы ext2/3, имеет ключ -я , который указывает объем дискового пространства для создания индексного узла, т.е.
если вы укажете -i 16384, то на каждые 16 килобайт дискового пространства будет создан индексный узел.
Я воспользуюсь самым простым вариантом — буду создавать индексный дескриптор на каждые 16 КБ дискового пространства, без возможности изменить это значение (по крайней мере, пока).
Последний общий момент, на котором стоит остановиться, — это размер блока.
Файловая система может обрабатывать блоки разного размера, я буду поддерживать блоки по 512, 1024, 2048 и 4096 байт — ничего необычного.
Это связано с тем, что с блоками, вписывающимися в страницу, проще работать (к этому мы вернемся чуть позже), но это совсем не обязательно; более того, больший размер блока может повысить производительность.
В общем, выбор правильного размера блока для классических файловых систем — довольно интересная тема.
Например, в известная книга об ОС предоставлена информация, что при размере блока 4 КБ в один блок уместится 60 - 70% файлов.
Чем больше файлов помещается в один блок, тем меньше фрагментация, тем выше скорость чтения, но и тем больше места теряется.
В нашем случае, помимо прочего, основным ограничителем файловой системы является размер блока — при размере блока в 4 КБ битовая карта свободных блоков может покрыть всего 128 МБ дискового пространства.
Вернемся к практике
Пришло время написать код. Начнем со структур, которые мы будем использовать, начиная с самых простых:Теги: #ядро Linuxstruct aufs_disk_super_block {
-
Как Разрабатывался Новый Дизайн Карт Maps.me
19 Oct, 24 -
Интересные Документы О Монополии Microsoft
19 Oct, 24 -
Действия, Документы И Семантика
19 Oct, 24 -
Долой «Веселье»!
19 Oct, 24
