Initramfs e dispositivos de bloco

Question

Nesta introdução a initramfs , Robert Landley menciona o seguinte como a motivação por trás dos ramfs.

But ramdisks actually waste even more memory due to caching. Linux is designed to cache all files and directory entries read from or written to block devices, so Linux copies data to and from the ramdisk into the "page cache" (for file data), and the "dentry cache" (for directory entries). The downside of the ramdisk pretending to be a block device is it gets treated like a block device.

A few years ago, Linus Torvalds had a neat idea: what if Linux's cache could be mounted like a filesystem? Just keep the files in cache and never get rid of them until they're deleted or the system reboots? Linus wrote a tiny wrapper around the cache called "ramfs", and other kernel developers created an improved version called "tmpfs" (which can write the data to swap space, and limit the size of a given mount point so it fills up before consuming all available memory). Initramfs is an instance of tmpfs.

Isso me leva a acreditar que o ramfs (e consequentemente o initramfs) é um mecanismo para expor a estrutura do cache interno como um sistema de arquivos - usando o driver initramfs.

Mas a existência do próprio cache não depende da existência de um dispositivo de bloco para armazenar em cache de ? Isso significaria que, mesmo para criar um sistema de arquivos baseado em memória RAM, precisaríamos criar (ou simular) um dispositivo de bloco de onde o ramfs iria armazenar em cache - o que parece o problema introduzido pelo initrd em primeiro lugar. Tenho certeza de que estou sentindo falta de alguma coisa aqui, mas não sei ao certo.

O arquivo cpio passado para o kernel também pode residir em um dispositivo de bloco (disco rígido, tipicamente), então, para montar o conteúdo do initramfs, o kernel ainda não precisaria de um driver de sistema de arquivos?

    

Answer 1

Para o ramsfs / initrams, o dispositivo para armazenar em cache o fs é "vazio". Se você olhar a descrição em /Documentation/filesystems/ramfs-rootfs-initramfs.txt :

Normally all files are cached in memory by Linux. Pages of data read from backing store (usually the block device the filesystem is mounted on) are kept around in case it's needed again, but marked as clean (freeable) in case the Virtual Memory system needs the memory for something else. Similarly, data written to files is marked clean as soon as it has been written to backing store, but kept around for caching purposes until the VM reallocates the memory. A similar mechanism (the dentry cache) greatly speeds up access to directories.

With ramfs, there is no backing store. Files written into ramfs allocate dentries and page cache as usual, but there's nowhere to write them to. This means the pages are never marked clean, so they can't be freed by the VM when it's looking to recycle memory.

Portanto, um "mecanismo para expor a estrutura do cache interno como um sistema de arquivos" não está errado, mas não como eu descreveria - é um sistema de arquivos que usa a estrutura de cache interna usual, mas não tem espaço para "fazer backup" (como ramdisk tinha), então somente vive no cache, e os mecanismos para invalidar e escrever páginas nunca são usados.

Quanto ao arquivo cpio , veja novamente ramfs-rootfs-initramfs.txt :

The old initrd was always a separate file, while the initramfs archive is linked into the linux kernel image. (The directory linux-*/usr is devoted to generating this archive during the build.)

Portanto, o cpio é carregado usando o mesmo método que o kernel carrega, que pode ser de um dispositivo de bloco, ou pela rede, ou por meio de um pombo, ou o que for. Não importa. O bootloader cuida disso, o kernel não precisa de um driver de sistema de arquivos.

    

Answer 2

O ponto de ramfs é que ele se livra do dispositivo de bloco. O conteúdo do sistema de arquivos é preenchido por meio da interface do sistema de arquivos e, como não há dispositivo de bloco de apoio, os dados permanecem no cache. No modo antigo, o armazenamento de apoio agia como um dispositivo de bloco no qual uma imagem do sistema de arquivos era gravada. Isso foi então montado como um sistema de arquivos. O problema com essa abordagem (RAM armazenada em cache na RAM) foi resolvido, não removendo o cache, mas removendo o dispositivo de bloco.

Sim, o arquivo cpio normalmente vem de um dispositivo de bloco, mas não necessariamente. Ele pode vir da rede, de um dispositivo de bloco simples, etc. O arquivo cpio também pode ser parte da imagem do kernel. É claro que deve haver um mecanismo para o gerenciador de partida carregar o kernel e o initramfs na RAM, mas esse é o problema do carregador de inicialização, não do kernel. O ponto do initramfs é que o sistema final pode ser muito diversificado, com uma dúzia de sistemas de arquivos diferentes, diferentes interfaces de unidades de disco de baixo nível, etc. Usando um initramfs, o kernel pode ser configurado para ser mais genérico , sem a necessidade de compilar em um milhão de drivers, que podem ser fornecidos como módulos. Na verdade, você não precisa de nenhum driver de sistema de arquivos no kernel, eles podem ser todos carregados sob demanda como módulos.