Come interagiscono pdflush, kjournald, swapd, ecc?

Recentemente ho visto una domanda che ha scatenato questo pensiero. Impossibile trovare una risposta qui o tramite la macchina di Google. Fondamentalmente, sono interessato a sapere come viene stratificata l'architettura I / O del kernel. Ad esempio, la kjournaldspedizione avviene pdflusho viceversa? La mia ipotesi è che pdflush(essendo più generico per l'I / O di archiviazione di massa) si collochi a un livello inferiore e innescherebbe SCSI / ATA / qualsiasi comando necessario per eseguire effettivamente le scritture e kjournaldgestisca le strutture di dati del file system di livello superiore prima di scrivere. Potevo vederlo anche al contrario, tuttavia, con l' kjournaldinterfacciamento diretto con le strutture dati del filesystem e il pdflushrisveglio di tanto in tanto per scrivere pagine sporche di pagecache sul dispositivo attraversokjournald. È 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.

Prima di discutere le specifiche riguardanti pdflush, kjournald, andkswapd`, otteniamo un piccolo retroscena sul contesto di ciò di cui stiamo parlando esattamente in termini di kernel Linux.

L'architettura GNU / Linux

L'architettura di GNU / Linux può essere pensata come 2 spazi:

• Utente
• nocciolo

Tra lo spazio utente e lo spazio del kernel si trova la libreria GNU C (glibc ). Ciò fornisce l'interfaccia di chiamata di sistema che collega il kernel alle applicazioni dello spazio utente.

Lo spazio del kernel può essere ulteriormente suddiviso in 3 livelli:

• Interfaccia di chiamata di sistema
• Codice kernel indipendente dall'architettura
• Codice dipendente dall'architettura

System Call Interface come suggerisce il nome, fornisce un'interfaccia tra glibcil kernel e. 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 è costituito dai componenti che sono codici specifici del processore e della piattaforma per una determinata architettura hardware.

Diagramma dell'architettura GNU / Linux

Per il resto di questo articolo, focalizzeremo 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 su come è strutturato il kernel GNU / Linux, possiamo approfondire un po 'di più il sottosistema VFS. Questo componente è responsabile di fornire l'accesso ai vari dispositivi di archiviazione a blocchi che alla fine si associano a un filesystem (ext3 / ext4 / ecc.) Su un dispositivo fisico (HDD / ecc.).

Diagramma di VFS

Questo diagramma mostra come un write()processo di un utente attraversa il VFS e alla fine arriva fino al driver del dispositivo in cui è scritto sul supporto di archiviazione fisico. Questo è il primo posto dove ci incontriamo pdflush. Questo è un demone che è responsabile per scaricare dati sporchi e blocchi buffer di metadati sul supporto di archiviazione in background. Il diagramma non mostra questo, ma c'è un altro demone, kjournaldche si trova accanto pdflush, eseguendo un'attività simile scrivendo blocchi di giornale sporchi su disco. NOTA: i blocchi journal sono il modo in cui i filesystem come ext4 e JFS tengono traccia delle modifiche al disco in un file, prima che avvengano tali modifiche.

I dettagli di cui sopra sono discussi ulteriormente in questo documento .

Panoramica dei write()passaggi

Per fornire una semplice panoramica delle operazioni del sistema di I / O, utilizzeremo un esempio in cui la funzione write()viene chiamata da un'applicazione User Space.

1. Un processo richiede di scrivere un file tramite la write()chiamata di sistema.
2. Il kernel aggiorna la cache della pagina mappata al file.
3. Un thread del kernel pdflush si occupa di scaricare la cache della pagina sul disco.
4. Il livello del file system riunisce ciascun buffer di blocco in un bio struct( fare riferimento a 1.4.3, "Livello di blocco" a pagina 23 ) e invia una richiesta di scrittura al livello del dispositivo a blocchi.
5. Il livello del dispositivo a blocchi riceve richieste dai livelli superiori ed esegue un'operazione di elevazione I / O e inserisce le richieste nella coda di richieste I / O.
6. Un driver di dispositivo come SCSI o altri driver specifici del dispositivo si occuperà dell'operazione di scrittura.
7. Un firmware del dispositivo disco esegue operazioni hardware come ricerca della testa, rotazione e trasferimento dei dati al settore sul piatto.

Sottosistema VMM

Continuando la nostra immersione più profonda, ora possiamo esaminare il sottosistema VMM. Questo componente è responsabile del mantenimento della coerenza tra memoria principale (RAM), scambio e supporto di archiviazione fisico. Il meccanismo principale per mantenere la coerenza è bdflush. Poiché le pagine di memoria sono considerate sporche, devono essere sincronizzate con i dati presenti sul supporto di memorizzazione. bdflushsi coordinerà con i pdflushdemoni per sincronizzare questi dati con il supporto di memorizzazione.

Diagramma di VMM

Scambiare

Quando la memoria di sistema diventa scarsa o il timer di scambio del kernel scade, il kswapddemone tenterà di liberare le pagine. Finché il numero di pagine libere rimane al di sopra free_pages_high, kswapdnon farà nulla. Tuttavia, se il numero di pagine libere scende di seguito, kswapdverrà avviato il processo di recupero delle pagine. Dopo kswapdaver contrassegnato le pagine per il trasferimento, bdflushsi occuperà di sincronizzare eventuali modifiche in sospeso al supporto di archiviazione, tramitepdflush demoni.

Riferimenti e ulteriori letture

• Architettura concettuale del kernel Linux
• Il diagramma dello stack I / O di Linux - ver. 0.1, 2012-03-06 - delinea lo stack I / O Linux a partire dal kernel 3.3
• Aggiornamento dei file system locali - in particolare la diapositiva n. 7
• Mappa del kernel Linux interattiva
• Comprensione della memoria virtuale in Red Hat Enterprise Linux 4
• Linee guida per prestazioni e ottimizzazione di Linux - in particolare le pagine 19-24
• Anatomia del kernel Linux
• Il caso della replica remota consapevole semantica