Con il primo avvio della Xandros abbiamo scoperto che il nostro eeepc usa ufs come file system per il primo disco SSD, quello contenente il sistema operativo. Non ne avevo mai sentito parlare, anche se in realtà l’ho sempre usato senza saperlo!
L’Aufs è una riscrittura di Unionfs, un file system nato per unire più partizioni in una unica virtuale. Le partizioni possono essere sia in sola lettura che in lettura scrittura e ad ognuna è associata un priorità di accesso rispetto alle altre.
Ma a cosa può mai servire una cosa del genere? Serve, serve e vi porto subito
un esempio. Quando usate una distribuzione live, come la Knoppix, la quale carica il sistema operativo e i programmi in memoria, pur continuando ad avere i files su CDROM, senza l’utilizzo di un filesystem come Aufs sarebbe stato molto difficile realizzare un tale sistema.
In questo caso esiste un file system a sola lettura (quello del CDROM, contente tutto il sistema operativo e le applicazioni) e un file system di lettura scrittura che solitamente risiede nella memoria stessa (RAM filesystem).
Settando che il file system su RAM abbia priorità maggiore di ppyquello su disco, otteniamo che possiamo modificare quelle che erano le impostazioni salvate sul CDROM e queste saranno sempre visibili (dato che hanno priorità maggiore). Pensiamo a quando il riconoscimento hardware della distribuzione trova nuove periferiche e ne scrive la configurazione su /etc, ad esempio, o quando noi stessi variamo dei parametri (risoluzione video, ecc.), oppure scarichiamo degli aggiornamenti da internet per aggiornare il systema.
Infine, se il RAM filesystem viene salvato (come fa la Puppy) su un file su
disco, siamo in grado di recuperare i cambiamenti che sono stati fatti, al
prossimo utilizzo della distribuzione live 🙂
Ora che abbiamo capito come funziona Aufs, possiamo chiederci come è
implementato nell’eeepc e per quale motivo sia stato utilizzato.
Partiamo dal primo punto. Se guardiamo cosa ci indica il programma gparted (lanciato dalla Puppy), vediamo che il disco SSD da 4GB è così suddiviso:
- /dev/sda1 EXT2 sola lettura, dimensione 3GB, usati 2,59GB
- /dev/sda2 EXT3 lettura/scrittura, dimensione 690MB
- /dev/sda3 FAT16 lettura/scrittura, dimensione 7,84MB
- /dev/sda4 FAT16 lettura/scrittura, dimensione 7,84MB
Precisiamo subito che le partizioni piccoline da 7,84MB col sistema FAT, hanno una utilità, ovvero sono quelle che permettono di effettuare un aggiornamento del BIOS utilizzando i programmi messi a disposizione da Asus, pertanto è conveniente che non vengano mai cancellate 😉
La prima partizione è grande 2/3 del disco e contiene il sistema operativo Xandros, mentre la seconda partizione su cui possiamo scrivere detiene l’altro 1/3 ed è dove risiedono tutte le modifiche che applichiamo al nostro sistema operativo (aggiornamenti, installazioni programmi, cambi di configurazioni, ecc).
Quello che possiamo notare è che dopo l’aggiornamento effettuato al primo avvio, ben 462MB sono stati utilizzati, pertanto ci rimangono 227MB per altri aggiornamenti/installazioni. Certo, più il sistema è datato e meno aggiornamenti di sicurezza saranno necessari in futuro, però forse quei 227MB potrebbero andarci strettini. Questo anche in virtù del fatto che la prima partizione ha 487MB liberi e che non verranno mai utilizzati (il file system è in sola lettura) 🙁
Un utilizzo più accurato del partizionamento avrebbe potuto dare più spazio libero alla nostra partizione di sistema, questo lo possiamo riconoscere. Per quanto riguarda l’installazione di nuovi programmi, possiamo sempre ricorrere al secondo SSD (quello da 16GB in cui risiede la nostra home): ci basta scaricare la versione binaria del programma, non quella pacchettizata e installarla su una cartella creata sul secondo disco SSD.
Tornando al secondo punto, ovvero perché è stato scelto di inserire questo file system, penso che la risposta sia veramente semplice: la Asus in questo modo ha potuto aggiungere un sistema di rispristino del sistema operativo allo stato iniziale, senza ricorrere a partizioni di ghost (come spesso avviene in windows, dove una partizione contiene l’immagine zippata del sistema operativo, da sovrascrivere alla partizione principale in caso di procedura di ripristino).
Con questo sistema si risparmia spazio e la procedura di ripristino è pressochè immediata: basta cancellare il contenuto della partizione /dev/sda2 e tutto torna come prima (tranne le eventuali modifiche di configurazioni salvate localmente sulla nostra home directory che risiede sul secondo disco).
Certo, dato che ci viene dato in dotazione un DVD di ripristino del sistema operativo può sembrare inutile avere l’opzione descritta sopra, ma ricordiamo che non avendo l’eeepc un lettore cdrom internamente, un eventuale ripristino sarebbe più problematico per la maggior parte delle persone, le quali dovrebbero procurarsi il lettore.
Luci (possibilità di ripristino veloce) ed ombre (spazio libero limitato) quindi sulla scelta di utilizzare questo filesystem, ma in piena libertà offertaci da Linux possiamo decidere di adottare una di queste strategie (sempre nell’ottica di tenere la Xandros, almeno per un bel po di tempo):
- Ridurre la partizione in sola lettura /dev/sda1 per saturare lo spazio utilizzato, e allargare la /dev/sda2 (potenzialmente una bella soluzione, solo che bisogna ricordare che se cancelliamo programmi non si libera spazio in /dev/sda1)
- Creare una partizione spaziosa sul secondo disco e aggiungerla con priorità maggiore su Aufs (lo svantaggio è che lo spazio su /dev/sda2 non verrà pressochè utilizzato).
- Cancellare la partizione /dev/sda2 ed ingrandire la /dev/sda1, convertirla in EXT3 e togliere il supporto Aufs (lo svantaggio è che perdiamo la possibilità di ripristino del sistema operativo)
La mia scelta è l’ultima, ovvero rinuncio alla possibilità del ripristino (che in ogni caso dubito che avrei mai usato) e rendo la Xandrox molto più maneggiabile… ma questo lo vedremo in un prossimo appuntamento 😉