Как работают pdflush, kjournald, swapd и т. Д.?

Недавно увидел вопрос, который вызвал эту мысль. Не могу найти ответ здесь или через Google. По сути, мне интересно знать, как устроена архитектура ядра ввода / вывода. Например, kjournaldотправка pdflushили наоборот? Мое предположение состоит в том, что pdflush(будучи более общим для ввода-вывода для запоминающих устройств большой емкости) будет сидеть на более низком уровне и запускать команды SCSI / ATA / любые другие, необходимые для фактического выполнения записи, и kjournaldобрабатывать структуры данных файловой системы более высокого уровня перед записью. Я мог видеть это и с другой стороны, однако, с kjournaldнепосредственным взаимодействием со структурами данных файловой системы и pdflushпросыпаясь время от времени, чтобы записать грязные страницы кэша страниц на устройство черезkjournald, Также возможно, что эти два не взаимодействуют вообще по некоторой другой причине.

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

Прежде чем мы обсудим особенности , касающиеся pdflush, kjournald, andkswapd`, давайте сначала получить немного о контексте того , что именно мы говорим в терминах ядра Linux.

Архитектура GNU / Linux

Архитектура GNU / Linux может рассматриваться как 2 пространства:

• пользователь
• ядро

Между пользовательским пространством и пространством ядра находится библиотека GNU C ( glibc). Это обеспечивает интерфейс системного вызова, который соединяет ядро ​​с приложениями пользовательского пространства.

Пространство ядра может быть разделено на 3 уровня:

• Интерфейс системного вызова
• Архитектурно-независимый код ядра
• Архитектурно-зависимый код

Интерфейс системного вызова, как следует из его названия, обеспечивает интерфейс между glibcядром и. Архитектурный Независимый Kernel Код состоит из логических единиц , таких как VFS (Virtual File System) и VMM (Virtual Memory Management). Архитектурный зависимый код является компонентами, процессор и платформо-зависимый код для конкретной аппаратной архитектуры.

Схема архитектуры GNU / Linux

В оставшейся части этой статьи мы сосредоточим наше внимание на логических единицах VFS и VMM в пространстве ядра.

Подсистемы ядра GNU / Linux

Подсистема VFS

С концепцией высокого уровня того, как структурировано ядро ​​GNU / Linux, мы можем углубиться в подсистему VFS. Этот компонент отвечает за предоставление доступа к различным блочным устройствам хранения, которые в конечном итоге отображаются на файловую систему (ext3 / ext4 / etc.) На физическом устройстве (HDD / etc.).

Схема ВФС

На этой диаграмме показано, как write()пользовательский процесс проходит через VFS и, в конечном счете, переходит к драйверу устройства, где он записывается на физический носитель данных. Это первое место, где мы встречаемся pdflush. Это демон, который отвечает за сброс грязных блоков буфера данных и метаданных на носитель данных в фоновом режиме. На диаграмме это не показано, но есть еще один демон, kjournaldкоторый сидит рядом pdflush, выполняя аналогичную задачу записи грязных блоков журнала на диск. ПРИМЕЧАНИЕ. Журнальные блоки - это то, как файловые системы, такие как ext4 и JFS, отслеживают изменения на диске в файле до того, как эти изменения произойдут.

Вышеуказанные детали обсуждаются далее в этой статье .

Обзор write()шагов

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

1. Процесс запрашивает запись файла через write()системный вызов.
2. Ядро обновляет кеш страниц, сопоставленный с файлом.
3. Поток ядра pdflush заботится о сбросе кеша страниц на диск.
4. Уровень файловой системы объединяет каждый блочный буфер в bio struct( см. 1.4.3, « Уровень блока» на стр. 23 ) и отправляет запрос на запись на уровень блочных устройств.
5. Уровень блочных устройств получает запросы от верхних уровней, выполняет операцию лифта ввода-вывода и помещает запросы в очередь запросов ввода-вывода.
6. Драйвер устройства, такой как SCSI или другие специфические драйверы устройства, позаботится об операции записи.
7. Прошивка дискового устройства выполняет аппаратные операции, такие как поиск головки, вращение и передача данных в сектор на диске.

Подсистема VMM

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

Схема ВММ

Обмен

Когда системной памяти становится мало или истекает таймер подкачки ядра, kswapdдемон будет пытаться освободить страницы. Пока количество свободных страниц остается выше free_pages_high, kswapdничего не поделаешь. Однако, если количество свободных страниц упадет ниже, то kswapdначнется процесс восстановления страницы. После того, kswapdкак пометил страницы для перемещения, bdflushпозаботится о синхронизации любых ожидающих изменений на носителе через pdflushдемоны.

Рекомендации и дальнейшие чтения

• Концептуальная архитектура ядра Linux
• Диаграмма стеков ввода-вывода в Linux - вер. 0.1, 2012-03-06 - в общих чертах описан стек ввода-вывода Linux начиная с ядра 3.3
• Обновление локальных файловых систем - в частности слайд № 7
• Интерактивная карта ядра Linux
• Понимание виртуальной памяти в Red Hat Enterprise Linux 4
• Рекомендации по производительности и настройке Linux - в частности, страницы 19-24
• Анатомия ядра Linux
• Кейс для семантической осведомленной удаленной репликации