La differenza tra initrd e initramfs?

Penso che tu abbia ragione in tutto.

La differenza è facile da vedere se segui i passaggi necessari all'avvio:

initrd

• Un ramdev viene creato il dispositivo a blocchi. È un dispositivo a blocchi basato su ram, ovvero un disco rigido simulato che utilizza la memoria anziché i dischi fisici.
• Il initrd il file viene letto e decompresso nel dispositivo, come se avessi fatto zcat initrd | dd of=/dev/ram0 o qualcosa di simile.
• Il initrd contiene un'immagine di un filesystem, quindi ora puoi montare il filesystem come al solito:mount /dev/ram0 /root . Naturalmente, i filesystem hanno bisogno di un driver, quindi se usi ext2, il driver ext2 deve essere compilato nel kernel.
• Fatto!

initramfs

• Un tmpfs è montato:mount -t tmpfs nodev /root . Il tmpfs non ha bisogno di un driver, è sempre sul kernel. Nessun dispositivo necessario, nessun driver aggiuntivo.
• Il initramfs viene decompresso direttamente in questo nuovo filesystem:zcat initramfs | cpio -i , o simili.
• Fatto!

E sì, si chiama ancora initrd in molti posti anche se è un initramfs , in particolare nei boot loader, poiché per loro è solo un BLOB. La differenza la fa il sistema operativo quando si avvia.

Dentry (e inode) cache

Il sottosistema del file system in Linux ha tre livelli. Il VFS (filesystem virtuale), che implementa l'interfaccia delle chiamate di sistema e gestisce l'attraversamento dei punti di montaggio e le autorizzazioni predefinite e i controlli dei limiti. Al di sotto ci sono i driver per i singoli filesystem e quelli a loro volta si interfacciano ai driver per i dispositivi a blocchi (dischi, schede di memoria, ecc.; le interfacce di rete fanno eccezione).

L'interfaccia tra VFS e filesystem sono diverse classi (è semplice C, quindi strutture contenenti puntatori a funzioni e simili, ma concettualmente è un'interfaccia orientata agli oggetti). Le tre classi principali sono inode , che descrive qualsiasi oggetto (file o directory) in un filesystem, dentry , che descrive la voce in una directory e file , che descrive il file aperto da un processo. Una volta montato, il driver del filesystem crea inode e dentry perché è root e gli altri vengono creati su richiesta quando il processo vuole accedere a un file e alla fine scadono. Questa è una cache di dentry e inode.

Sì, significa che per ogni file aperto e qualsiasi directory fino alla radice ci devono essere inode e dentry strutture allocate nella memoria del kernel che lo rappresentano.

Cache della pagina

In Linux, ogni pagina di memoria che contiene dati userland è rappresentata da page unificato struttura. Questo potrebbe contrassegnare la pagina come anonima (potrebbe essere scambiata per scambiare spazio se disponibile) o associarla a inode su qualche filesystem (potrebbe essere riscritto e riletto dal filesystem) e può far parte di un numero qualsiasi di mappe di memoria, cioè visibile nello spazio degli indirizzi di qualche processo. La somma di tutte le pagine attualmente caricate in memoria è la cache delle pagine.

Le pagine vengono utilizzate per implementare l'interfaccia mmap e mentre le normali chiamate di sistema di lettura e scrittura possono essere implementate dal filesystem con altri mezzi, la maggior parte delle interfacce utilizza una funzione generica che utilizza anche le pagine. Esistono funzioni generiche, che quando viene richiesta la lettura del file allocano le pagine e chiamano il filesystem per riempirle, una per una. Per i filesystem basati su dispositivi a blocchi, calcola solo gli indirizzi appropriati e delega questo riempimento al driver del dispositivo a blocchi.

ramdev (ramdisk)

Ramdev è un normale dispositivo a blocchi. Ciò consente di sovrapporre qualsiasi filesystem su di esso, ma è limitato dall'interfaccia del dispositivo a blocchi. E questo ha solo metodi per compilare una pagina assegnata dal chiamante e riscriverla. Questo è esattamente ciò che è necessario per dispositivi a blocchi reali come dischi, schede di memoria, memorie di massa USB e simili, ma per ramdisk significa che i dati esistono in memoria due volte, una volta nella memoria del ramdev e una volta nella memoria allocata dal chiamante.

Questo è il vecchio modo di implementare initrd . Dai tempi in cui initrd era un evento raro ed esotico.

tmpfs

Tmpfs è diverso. È un filesystem fittizio. I metodi che fornisce a VFS sono il minimo indispensabile per farlo funzionare (come tale è un'eccellente documentazione di cosa dovrebbero fare i metodi inode, dentry e file). I file esistono solo se sono presenti inode e dentry corrispondenti nella cache degli inode, creati quando il file viene creato e mai scaduti a meno che il file non venga eliminato. Le pagine sono associate ai file quando i dati vengono scritti e altrimenti si comportano come quelle anonime (i dati possono essere memorizzati per lo scambio, page le strutture rimangono in uso finché esiste il file).

Ciò significa che non ci sono copie extra dei dati in memoria e il tutto è molto più semplice e per questo anche leggermente più veloce. Utilizza semplicemente le strutture di dati, che fungono da cache per qualsiasi altro filesystem, in quanto è l'archiviazione primaria.

Questo è il nuovo modo di implementare initrd (initramfs , ma l'immagine è ancora chiamata semplicemente initrd ).

È anche il modo di implementare la "memoria condivisa posix" (che significa semplicemente che tmpfs è montato su /dev/shm e le applicazioni sono libere di creare file lì e di mmaparle; semplice ed efficiente) e recentemente anche /tmp e /run (o /var/run ) spesso hanno tmpfs montato soprattutto sui notebook per evitare che i dischi debbano girare o evitare un po' di usura in caso di SSD.