Initramfs и блочные устройства
С awk в режиме абзаца
awk -v RS= '{match($0, /lock mode=[^\n]+/);
print RSTART? substr($0, RSTART, RLENGTH): "NA"}' file
RS = заставляет каждый абзац обрабатываться как отдельная запись. Вызов match заполняет координаты режима блокировки = .... в предварительно определенные переменные RSTART и RLENGTH . Если RSTART не равно нулю, печатается подстрока, соответствующая RSTART и RLENGTH , в противном случае печатается NA
{{ 1}}
Смысл ramfs в том, что он избавляется от блочного устройства. Содержимое файловой системы заполняется через интерфейс файловой системы, и из-за отсутствия блочного устройства поддержки данные остаются в кэше. Раньше резервное хранилище действовало как блочное устройство, в которое был записан образ файловой системы. Затем он был смонтирован как файловая система. Проблема с этим подходом (ОЗУ кэшировалась в ОЗУ) была решена не удалением кеша, а удалением блочного устройства.
Да, архив cpio обычно поступает с блочного устройства, но не обязательно. Он может поступать из сети, необработанного блочного устройства и т. Д. Архив cpio может также быть частью образа ядра. Конечно, у загрузчика должен быть механизм для загрузки ядра и initramfs в ОЗУ, но это проблема загрузчика, а не ядра. Суть initramfs в том, что конечная система может быть очень разнообразной, с дюжиной или около того различных файловых систем на выбор, различными интерфейсами дисководов нижнего уровня и т. Д. Используя initramfs, ядро можно настроить на более универсальное , без необходимости компилировать миллион драйверов, которые вместо этого могут быть предоставлены в виде модулей. Фактически, вам не нужны никакие драйверы файловой системы в ядре, все они могут быть загружены по запросу в виде модулей.
Для ramsfs / initrams устройство для кэширования файловой системы «пусто». Если вы посмотрите описание в /Documentation/filesystems/ramfs-rootfs-initramfs.txt :
Обычно все файлы кэшируются в памяти Linux. Страницы данных, считанные из резервного хранилища (обычно это блочное устройство, на котором установлена файловая система), хранятся на случай, если они снова понадобятся, но помечены как чистые (бесплатные) в случае, если {{1 }} Системе виртуальной памяти нужна память для чего-то еще. Точно так же данные , записанные в файлы, помечаются как чистые, как только они были записаны в резервное хранилище , но сохраняются для целей кэширования, пока виртуальная машина не перераспределит память . Подобный механизм (кэш-память dentry) значительно ускоряет доступ к каталогам .
У ramfs нет резервного хранилища. Файлы, записанные в ramfs, как обычно выделяют данные и кеш страниц, но их некуда записать. Это означает, что страницы никогда не помечаются как чистые, поэтому они не могут быть освобождены с помощью {{ 1}} ВМ, когда она хочет переработать память.
Таким образом, «механизм раскрытия внутренней структуры кеша как файловой системы» не является неправильным, но я бы не описал его так: это файловая система, которая использует обычную внутреннюю структуру кеша, но не имеет места для «резервного копирования» (как и ramdisk ), поэтому он только живет в кэше, а механизмы аннулирования и обратной записи страниц никогда не используются.
Что касается файла cpio , снова посмотрите на ramfs-rootfs-initramfs.txt :
Старый initrd всегда был отдельным файлом, а архив initramfs - {{ 1}} связан с образом ядра Linux.(Каталог linux - * / usr предназначен для создания этого архива во время сборки.)
Итак, cpio загружается с использованием того же метода, что и ядро, которое может быть с блочного устройства, или по сети, или через голубятню, или что-то еще. Неважно. Об этом позаботится загрузчик, ядру не нужен драйвер файловой системы.