Gestione della flash

La flash supporta solo un numero finito di scritture per questo bisogna evitare di utilizzarla per file scritti molto spesso come quelli temporanei o i log. Inoltre è auspicabile avere il root file-system in modalità a sola lettura per evitare di provocare danni durante il funzionamento del sistema.

Uso dei symbolic link

L'approccio più semplice è sostituire i file che necessitano di scrittura con dei link simbolici. E' comodo distinguere 2 possibili target di questi:

Il processo di spostamento dei file/directory è implementato in gen.sh. Una volta spostati viene generata una immagine per la gerarchia sotto /rw da mettere sulla partizione flash persistente e un tarball con l'immagine iniziale del ramdisk. Durante il boot del sistema target il mount di questi file-system viene fatto assai presto nella fase di single-user (le script sono presenti in /etc/rcS.d) da mountspec.sh lanciata come S03mountspec.sh.

Il problema di questo metodo è che dobbiamo identificare le directory e i file che vanno spostati nelle are /rw e /ram. Di norma i primi si trovano sotto /etc, mentre i secondi sotto /var ma può capitare del software, soprattutto se non pacchtti Debian quindi aderenti alla policy, che non rispetta queste regole.

Compressione del root file-system con cloop

Grazie al fatto che abbiamo eliminato dal file-system l'accesso in scrittura possiamo applicare a questo delle tecniche di compressione. Tra le varie alternative segnaliamo la compressed loopback device o cloop in breve (vedi http://en.wikipedia.org/wiki/Cloop). La compressione viene fatta a livello di dispositivo a blocchi e non quindi a livello di file-system permettendo così di ottenere una compressione migliore e semplificarne il funzionamento. Questa tecnologia è utilizzate, per esempio, nella famosa distribuzione Knoppix.

Dato che la compressione è fatta a livello di dispositivo bisogna prima generare il file-system root e poi creare l'immagine del dispositivo con il comando create_compressed_fs (vedi gen.sh per i dettagli). Per caricare questa device è necessario creare un piccolo file-system di boot. Il modo migliore per farlo è utilizzare busybox. Sul sito di questo software ci sono giaà delle script (buidlroot) che generano dei root file-system minimali.

Nel file-system così creato è necessario sostituire il processo init con una piccola script init.cloop che provvede a:

Uso di aufs

Uno dei difetti dell'utilizzo dei link simbolici è che bisogna indentificare i file aperti in scrittura durante il funzionamento del sistema. Un'alternativa è utilizzare un file system che sovrapponga in modo trasparente la partizione in lettura/scrittua a quella in sola lettura compressa. Tra le varie alternative è stato utilizzato aufs, ovvero Another Unionfs. Grazie a questo file-system possiamo vedere diverse gerarchie sovrapposte. Nel nostro caso avremmo il root file-system di base al quale sarà sovrapposto quello in lettura/scrittura, sul quale verrano ridirezionate le scritture. Per la parte ram-disk useremo ancora la tecnica dei link simbolici, anche se sarebbe possibile avere la sovrapposizione pure di questa area. Il problema è che in questo caso la semantica su dove effettuare la scrittura diventa complessa. Nel caso di più branch a scrittura è necessario tenere ben presente le regole descritte nel manuale aufs.

Utilizzando aufs il processo di avvio del sistema è leggermente diverso: la preparazione del root file-system avviene completamente nella script di init e quindi non c'è bisogno di aggiungere nulla nella fase di boot in single user del sistema finale. I passi eseguiti in tale script sono:

Dopo un po' di tempo di utilizzo tipico del sistema è utile controllare la partizione a lettura/scrittura e il ram-disk per verificare quali file sono creati.