Ваше описание процесса не совсем верное.
Ядро отслеживает, какие пути являются точками монтирования. Как именно это происходит, зависит от ядра, но обычно информация хранится в виде путей. Например, ядро запоминает «/
— это файловая система, /media/cdrom
— это файловая система, /proc
— это эта файловая система» и т. д. Обычно вместо таблица сопоставления строк пути со структурами данных, представляющими смонтированные файловые системы, ядро хранит таблицы для каждого каталога. Данные, связанные с записью каталога, классически называются dentry. Есть dentry для корня, и в каждом каталоге есть dentry для каждого файла в этом каталоге, который помнит ядро. dentry содержит указатель на структуру inode, а inode содержит указатель на структуру данных файловой системы для файловой системы, в которой находится файл. В точке монтирования связанная файловая система отличается от связанной файловой системы родительского dentry, и есть дополнительные метаданные для отслеживания точки монтирования. Таким образом, в типичной архитектуре ядра Unix dentry для /
содержит указатель на информацию о корневой файловой системе в дополнение к указателю на индексный дескриптор, содержащий корневой каталог; dentry для /proc
(при условии, что это точка монтирования) содержит указатель на информацию о файловой системе proc и т.д.Если /media/cdrom
является точкой монтирования, но не /media
, ядро запоминает в dentry для /media
, что нельзя забывать о это: помнить о /media
— это не просто вопрос кэширования для повышения производительности, необходимо помнить о существовании точки монтирования /media/cdrom
.
Для Linux вы можете найти документацию в документации ядра,на этом сайте и в других местах в Интернете. Брюс Филдс хорошо изложил тему.
Когда ядру дается указание получить доступ к файлу, оно обрабатывает имя файла по одному компоненту, разделенному косой чертой, и каждый раз ищет компонент. Если он находит символическую ссылку, он переходит по ней. Если он находит точку монтирования, никакой специальной обработки на самом деле не требуется: просто индексные дескрипторы присоединяются к другому каталогу.
Процесс не использует номера инодов, он следует указателям. Номера инодов — это способ дать уникальный идентификатор каждому файлу в данной файловой системе вне ядра: на диске и для приложений. Существуют файловые системы, у которых нет уникальных номеров инодов; драйверы файловой системы обычно пытаются создать один, но это не всегда работает, особенно с сетевыми файловыми системами (например, если сервер экспортирует дерево каталогов, содержащее точку монтирования, может быть перекрытие между набором инодов выше и ниже этой точки монтирования точка). Строки, которые сопоставляют имя с номером inode, — это то, как работает типичная файловая система на диске, если она поддерживает жесткие ссылки; файловые системы, которые не поддерживают жесткие ссылки, на самом деле не нуждаются в концепции номера инода.
Обратите внимание, что информация о точках монтирования хранится только в памяти. Когда вы монтируете файловую систему, это не изменяет каталог, поверх которого монтируется файловая система. Этот каталог просто скрыт корнем смонтированной файловой системы.
Вы можете подтвердить, что своп активирован и сколько используется:
swapon --show
Кроме того, если вы хотите проверить использование памяти без htop, вы можете использовать:
free
Тем не менее, то, что вы уже показали, указывает что у вас, вероятно, нет проблем со свопом.
Своп настроен правильно, и мы можем видеть это на опубликованном изображении.
Нет отдельного шага для активации свопа. Своп используется только тогда, когда в системе заканчивается оперативная память. В вашей системе достаточно оперативной памяти для всех запущенных приложений.
На опубликованном вами изображении видно, что объем подкачки составляет 7,75 ГБ, и он не используется.