Recentemente ho visto una domanda che ha acceso questo pensiero. Non sono riuscito a trovare davvero una risposta qui o tramite la macchina di Google. Fondamentalmente, mi interessa sapere come è strutturata l'architettura I/O del kernel. Ad esempio, kjournald spedisci a pdflush o viceversa? La mia ipotesi è che pdflush (essendo più generico per l'I/O di archiviazione di massa) si collocherebbe a un livello inferiore e attiverebbe i comandi SCSI/ATA/qualsiasi cosa necessaria per eseguire effettivamente le scritture e kjournald gestisce le strutture di dati del filesystem di livello superiore prima di scrivere. Potrei vedere anche il contrario, però, con kjournald interfacciandosi direttamente con le strutture dati del filesystem e pdflush svegliarsi ogni tanto per scrivere pagine sporche di pagecache sul dispositivo tramite kjournald . È anche possibile che i due non interagiscano affatto per qualche altro motivo.
Fondamentalmente: Ho bisogno di un modo per visualizzare (grafico o solo una spiegazione) l'architettura di base utilizzata per inviare l'I/O alla memoria di massa all'interno del kernel Linux.
Risposta accettata:
Prima di discutere le specifiche relative a pdflush , kjournald, and kswapd`, per prima cosa facciamo un po' di background sul contesto di cosa esattamente stiamo parlando in termini di kernel Linux.
L'architettura GNU/Linux
L'architettura di GNU/Linux può essere pensata come 2 spazi:
- Utente
- kernel
Tra lo Spazio utente e Spazio del kernel si trova la libreria GNU C (glibc ). Ciò fornisce l'interfaccia di chiamata di sistema che connette il kernel alle applicazioni dello spazio utente.
Il Kernel Space può essere ulteriormente suddiviso in 3 livelli:
- Interfaccia di chiamata di sistema
- Codice del kernel indipendente dall'architettura
- Codice dipendente dall'architettura
Interfaccia di chiamata di sistema come suggerisce il nome, fornisci un'interfaccia tra glibc e il nocciolo. Il Codice del kernel indipendente dall'architettura comprende le unità logiche come VFS (Virtual File System) e VMM (Virtual Memory Management). Il codice dipendente dall'architettura sono i componenti che costituiscono il codice specifico del processore e della piattaforma per una determinata architettura hardware.
Diagramma dell'architettura GNU/Linux
Per il resto di questo articolo, concentreremo la nostra attenzione sulle unità logiche VFS e VMM all'interno dello spazio del kernel.
Sottosistemi del kernel GNU/Linux
Sottosistema VFS
Con un concetto di alto livello di come è strutturato il kernel GNU/Linux possiamo approfondire un po' il sottosistema VFS. Questo componente è responsabile di fornire l'accesso ai vari dispositivi di archiviazione a blocchi che alla fine vengono mappati su un filesystem (ext3/ext4/ecc.) su un dispositivo fisico (HDD/ecc.).
Diagramma di VFS
Questo diagramma mostra come un write() dal processo di un utente attraversa il VFS e alla fine arriva al driver del dispositivo dove viene scritto sul supporto di archiviazione fisico. Questo è il primo posto in cui incontriamo pdflush . Questo è un demone che è responsabile dello svuotamento dei dati sporchi e dei blocchi del buffer dei metadati sul supporto di memorizzazione in background. Il diagramma non lo mostra ma c'è un altro demone, kjournald , che si trova accanto a pdflush , eseguendo un'attività simile scrivendo blocchi di giornale sporchi su disco. NOTA: I blocchi del diario sono il modo in cui i filesystem come ext4 e JFS tengono traccia delle modifiche al disco in un file, prima che avvengano.
I dettagli di cui sopra sono discussi ulteriormente in questo documento.
Panoramica di write() passaggi
Per fornire una semplice panoramica delle operazioni del sistema di I/O, utilizzeremo un esempio in cui la funzione write() viene chiamato da un'applicazione User Space.
- Un processo richiede di scrivere un file tramite
write()chiamata di sistema. - Il kernel aggiorna la cache della pagina mappata sul file.
- Un thread del kernel pdflush si occupa di svuotare la cache della pagina su disco.
- Il livello del file system mette insieme ogni buffer di blocco in una
bio struct(fare riferimento a 1.4.3, "Livello blocco" a pagina 23) e invia una richiesta di scrittura al livello dispositivo a blocchi. - Il livello del dispositivo a blocchi riceve le richieste dai livelli superiori ed esegue un'operazione di I/O elevator e inserisce le richieste nella coda delle richieste I/O.
- Un driver di dispositivo come SCSI o altri driver specifici del dispositivo si occuperà dell'operazione di scrittura.
- Un firmware del dispositivo disco esegue operazioni hardware come la ricerca della testina, la rotazione e il trasferimento dei dati al settore sul piatto.
Sottosistema VMM
Continuando la nostra immersione più approfondita, ora possiamo esaminare il sottosistema VMM. Questo componente è responsabile del mantenimento della coerenza tra la memoria principale (RAM), lo scambio e il supporto di archiviazione fisico. Il meccanismo principale per mantenere la coerenza è bdflush . Poiché le pagine di memoria sono ritenute sporche, devono essere sincronizzate con i dati presenti sul supporto di archiviazione. bdflush si coordinerà con pdflush demoni per sincronizzare questi dati con il supporto di memorizzazione.
Diagramma di VMM
Scambia
Quando la memoria di sistema diventa scarsa o il timer di scambio del kernel scade, kswapd demone tenterà di liberare le pagine. Finché il numero di pagine libere rimane al di sopra di free_pages_high , kswapd non farà nulla. Tuttavia, se il numero di pagine libere scende al di sotto, allora kswapd avvierà il processo di reclamo della pagina. Dopo kswapd ha contrassegnato le pagine per il trasferimento, bdflush si occuperà di sincronizzare eventuali modifiche in sospeso sul supporto di memorizzazione, tramite il pdflush demoni.
Riferimenti e ulteriori letture
- Architettura concettuale del kernel Linux
- Il diagramma dello stack di I/O di Linux – ver. 0.1, 2012-03-06 – delinea lo stack di I/O Linux a partire dal kernel 3.3
- Aggiornamento dei file system locali, in particolare diapositiva n. 7
- Mappa interattiva del kernel Linux
- Capire la memoria virtuale in Red Hat Enterprise Linux 4
- Linee guida per l'ottimizzazione e le prestazioni di Linux, in particolare le pagine 19-24
- Anatomia del kernel Linux
- Il caso della replica remota sensibile alla semantica