[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home] [volume] [parte]


Capitolo 172.   File system compressi

In alcune situazioni può essere conveniente l'utilizzo di un file system compresso. Se il file system deve continuare a essere accessibile normalmente, è necessario utilizzare strumenti appositi, assieme a delle estensioni appropriate nel kernel per consentire l'accesso ai dati contenuti.

In generale, ci si può aspettare che un file system compresso funzioni correttamente esclusivamente quando questo è stato realizzato per accedervi in sola lettura; diversamente, un file system compresso che preveda e consenta la modifica dei dati, per quanto tecnicamente fattibile, sarebbe troppo poco affidabile e sarebbero maggiori i problemi rispetto ai vantaggi del suo utilizzo.

Una caratteristica comune dei file system compressi è la dimensione dei blocchi: solitamente a blocchi più grandi corrispondono prestazioni di compressione migliori. La tabella 172.1 riepiloga i valori che normalmente si possono utilizzare.

Tabella 172.1. Dimensioni tipiche dei blocchi di un file system compresso.

512*20 512 byte 512*21 1 024 byte
512*22 2 048 byte 512*23 4 096 byte
512*24 8 192 byte 512*25 16 384 byte
512*26 32 768 byte 512*27 65 536 byte

A fianco di file system compressi, veri e propri, si possono considerare anche sistemi basati sulla compressione trasparente dei singoli file; in tal caso non c'è più la necessità di determinare la dimensione dei blocchi.

172.1   Cloop

Con i sistemi GNU/Linux è possibile realizzare e accedere a un file system compresso denominato Cloop. (1) Il nome lascia intendere che si tratti di un file system contenuto in un file-immagine, compresso successivamente: Compressed loop.

La compressione è organizzata in blocchi, costituiti da multipli di 512 byte; l'accesso a un file system Cloop avviene attraverso l'utilizzo di un modulo apposito del kernel (cloop.o), con il quale si rende disponibile poi un file di dispositivo che appare come quello di un file system normale, ma in sola lettura. Si osservi che per il momento, Cloop consente di accedere a un solo file system compresso per volta.

Cloop nasce dall'esigenza di permettere a un CD-ROM o a un DVD-ROM di contenere più dati della propria capacità nominale, mantenendo un accesso fluido; così, si mostra generalmente l'utilizzo di Cloop in riferimento a file system di tipo ISO 9660 (CD e DVD). Tuttavia, in generale conviene usare sempre solo questo tipo di file system, se si considera che è consentito un accesso in sola lettura e che altre caratteristiche di file system più complessi servirebbero solo ad aumentarne inutilmente la dimensione.

Per poter gestire un file system Cloop è necessario disporre degli strumenti necessari alla compressione ed eventualmente all'estrazione di un file-immagine Cloop, oltre al modulo compilato per il proprio kernel.

Per arrivare ad avere un file system compresso, la prima cosa da fare è realizzare il file-immagine di questo, cosa che di solito si fa con strumenti quali mkisofs o mkhybrid (capitolo 170), quindi si passa alla compressione usando normalmente create_compressed_fs secondo uno dei due schemi seguenti:

create_compressed_fs immagine_originale 65536 > immagine_cloop
cat immagine_originale | create_compressed_fs - 65536 > immagine_cloop

Il valore numerico che appare come secondo argomento di create_compressed_fs è la dimensione dei blocchi espressa in byte; generalmente si indica il valore massimo, pari a 65 536, per ottenere la compressione migliore. Dovrebbe essere possibile indicare valori da 512 a 65 536, secondo quanto riportato nella tabella 172.1.

L'esempio seguente mostra la creazione di un file system ISO 9660 con le estensioni Rock Ridge, a partire dal contenuto della directory /usr/, che viene compresso per generare il file usr.cloop:

mkisofs -R /usr | create_compressed_fs - 65536 > usr.cloop[Invio]

Se per qualche ragione fosse necessario ricreare il file-immagine di partenza, si può usare extract_compressed_fs:

extract_compressed_fs immagine_cloop > immagine_originale
cat immagine_cloop | extract_compressed_fs - > immagine_originale

Per accedere al file system compresso senza estrarlo è necessario il modulo cloop.o, che deve essere stato compilato espressamente per il proprio tipo di kernel. La descrizione della procedura da seguire per questo è allegata ai sorgenti di Cloop e qui non viene descritta. Una volta installato correttamente il modulo (probabilmente è necessario avviare depmod -a per ricostruire le dipendenze tra i moduli), lo si deve caricare con l'indicazione contestuale del file contenente l'immagine compressa a cui si vuole accedere:

modprobe cloop file=immagine_cloop[Invio]

Oppure:

insmod cloop.o file=immagine_cloop[Invio]

Se si omette l'indicazione dell'argomento file=..., si ottiene una segnalazione di errore e il modulo non viene caricato. Tornando all'esempio già visto, si potrebbe trattare del file usr.cloop collocato nella directory radice del file system in uso:

modprobe cloop file=/usr.cloop[Invio]

cloop: Welcome to cloop v0.67
cloop: /usr.cloop: 12326 blocks, 65536 bytes/block, \
  \largest block is 65562 bytes.

Si ricorda che si può accedere a un solo file system Cloop per volta.

Dopo aver caricato il modulo si può accedere al file system come se questo fosse nella sua dimensione normale, non compresso, facendo riferimento a un file di dispositivo speciale, che di solito è meglio creare al volo:

mknod /dev/cloop b 240 0[Invio]

Quando si ha la disponibilità del file di dispositivo /dev/cloop, si può innestare il file system nel modo consueto:

mount -o ro -t tipo /dev/cloop punto_di_innesto

Tornando all'esempio già visto, se il file system è di tipo ISO 9660 e contiene quanto deve trovarsi nella directory /usr/, si può usare il comando seguente:

mount -o ro -t iso9660 /dev/cloop /usr[Invio]

172.2   Squashfs

Utilizzando un sistema con kernel Linux è disponibile anche il file system compresso Squashfs. (2) A differenza di Cloop, il file system ha caratteristiche proprie e non viene generato a partire da un altro tipo di file system. In pratica, il file system viene generato a partire dai dati da archiviare e non da un altro file system non compresso.

La creazione del file system avviene per mezzo del programma mksquashfs, che viene usato in uno dei due modi seguenti:

mksquashfs percorso file_squashfs [opzioni] [-e directory_esclusa...] 
mksquashfs percorso_1 percorso_2... file_squashfs [opzioni] [-e directory_esclusa...] 

In generale, i percorsi indicati, che possono essere file o directory intere, vengono copiati all'interno del file-immagine indicato come ultimo argomento prima delle opzioni. Tuttavia, l'utilizzo di una o dell'altra forma cambia il modo di inserire i dati relativi nel file-immagine di destinazione: se si archivia una directory soltanto, è il suo contenuto ad apparire nella directory radice del file system che viene generato, mentre in presenza di più percorsi (riferiti indifferentemente a file o a directory), questi vengono riprodotti nella destinazione mantenendo l'ultimo nome del percorso di origine. In generale, anche se sembra difficile da descrivere, in pratica questo funzionamento è quello intuitivo; si osservino i due esempi seguenti:

mksquashfs /usr/bin bin.sqsh[Invio]

mksquashfs /usr/bin /usr/sbin xbin.sqsh[Invio]

Nel primo caso si ottiene il file bin.sqsh, contenente un file system di tipo squashfs in cui, a partire dalla directory radice si trovano subito i file eseguibili contenuti nella directory di origine; invece, nel secondo caso il file system contenuto in xbin.sqsh si compone delle directory /bin/ e /sbin/.

Oltre all'opzione -e che si vede indicata alla fine della riga di comando, può essere utile l'opzione -b n, con cui si richiede espressamente l'utilizzo di blocchi di una certa dimensione. Il valore predefinito di questi blocchi è 32 768 e dovrebbe essere possibile usare blocchi da 512 a 65 536 secondo la scansione della tabella 172.1.

Per poter accedere a un file system di tipo Squashfs è necessario un kernel adatto, ma per questo potrebbe essere necessario modificare il sorgente del kernel attraverso un file di differenze. Quando il kernel è in grado di leggere il file system di tipo Squashfs, basta innestarlo come se fosse un file-immagine normale:

mount -o loop -o ro -t squashfs /usr.sqsh /usr[Invio]

Come si può intuire, l'esempio mostra l'innesto del file system contenuto nel file-immagine /usr.sqsh a partire dalla directory /usr/.

172.3   Cramfs

Il file system compresso Cramfs, (3) per un kernel Linux, è molto simile per funzionamento a Squashfs, ma con qualche possibilità in meno; tuttavia rimane il primo a essere disponibile nel sorgente del kernel Linux senza bisogno di procurarsi file di differenze o moduli particolari. Anche in questo caso si comincia dalla creazione del file-immagine compresso, in modo simile a Squashfs, ma con il limite di una sola directory di origine:

mkcramfs -b dimensione_blocchi [altre_opzioni] directory_di_origine file_cramfs

Per innestare il file-immagine si procede in modo simile a quanto già presentato con Squashfs:

mount -o loop -o ro -t cramfs file_immagine directory_di_innesto

172.4   Zisofs

Il file system Zisofs è in realtà un meccanismo di compressione di file singoli. In pratica, si parte da un ramo di una directory e se ne crea una sorta di copia, dove i file normali sono compressi, mentre tutto il resto rimane come prima (sottodirectory, collegamenti, ecc.). La gerarchia che si ottiene, teoricamente, può essere usata in lettura come se i file non fossero compressi, ma per questo occorre che il kernel sia predisposto allo scopo. In pratica, questa tecnica si usa per i file system ISO 9660 dei CD-ROM o dei DVD-ROM, come estensione specifica di GNU/Linux allo standard Rock Ridge.

La prima fase nella preparazione di un file system compresso, secondo questa tecnica, è quindi la creazione di una copia del ramo che interessa, compresso con mkzftree, che fa parte di Zisofs-tools: (4)

mkzftree [opzioni] directory_origine directory_di_destinazione
mkzftree -F [altre_opzioni] origine destinazione

A titolo di esempio, si supponga di voler archiviare una parte dei file che servono al funzionamento del sistema operativo in un CD-ROM; si tratta precisamente delle sole directory /bin/, /etc/, /lib/ e /sbin/. La prima fase consiste nella creazione di una nuova gerarchia compressa, per esempio a partire da /var/tmp/archiviazione/, che viene creata appositamente:

mkdir /var/tmp/archiviazione[Invio]

mkzftree /bin /var/tmp/archiviazione/bin[Invio]

mkzftree /etc /var/tmp/archiviazione/etc[Invio]

mkzftree /lib /var/tmp/archiviazione/lib[Invio]

mkzftree /sbin /var/tmp/archiviazione/sbin[Invio]

Al termine di queste operazioni, se si va a controllare il contenuto della directory /var/tmp/archiviazione/, si può avere l'impressione che nulla sia cambiato, a parte la dimensione dei file e il loro contenuto effettivo.

Teoricamente, se il file /etc/magic è stato aggiornato correttamente, dovrebbe essere possibile riconoscere questi file come zisofs; tuttavia, potrebbe essere necessario copiarli al di fuori del loro contesto per individuarli come tali.

Nella struttura creata in questo modo, si possono anche inserire file non compressi, come potrebbero essere i file necessari all'avvio del sistema (il kernel e altri), oppure un file di spiegazioni per chi dovesse tentare di leggere i dati senza sapere come fare.

Nel modello sintattico appare in evidenza la possibilità di usare l'opzione -F (ovvero --file). Questa opzione è utile quando l'origine e la destinazione possono essere qualcosa di diverso da directory. In pratica, con questa opzione si può comprimere anche un file singolo, mentre altrimenti si otterrebbe una segnalazione di errore.

Una volta realizzata la struttura, si passa normalmente alla creazione del file-immagine, con gli strumenti soliti, specificando che si va a creare un file system con estensioni Zisofs. Si osservi che in questo caso non ha più senso inserire estensioni Joliet e nello stesso modo non serve più la creazione di file TRANS.TBL. Viene mostrato un modello semplificato per l'uso di mkisofs:

mkisofs  -z {-r|-R} [altre_opzioni] -o file_immagine directory

Per esempio, per creare il file-immagine /var/tmp/immagine.iso dal contenuto di /var/tmp/archiviazione/, dovrebbe essere sufficiente agire in questo modo:

mkisofs -z -R -o /var/tmp/immagine.iso /var/tmp/archiviazione[Invio]

Successivamente si deve passare all'incisione del CD a partire dall'immagine (si veda per questo il capitolo 170).

Quando si innesta un CD-ROM realizzato con le estensioni Zisofs, se il sistema operativo è in grado di riconoscerle, dovrebbe leggere i dati in modo trasparente, senza lasciare avvertire che si tratta di dati compressi; tuttavia rimane il fatto che la dimensione dei file potrebbe risultare fasulla se letta con gli strumenti normali. Nel caso particolare di un sistema GNU/Linux, occorre che il kernel sia stato compilato includendo le funzionalità seguenti:

In mancanza di queste estensioni, la lettura dei dati richiede un'estrazione manuale, sempre con l'uso di mkzftree, ma questa volta con l'opzione -u:

mkzftree -u [altre_opzioni] directory_origine directory_di_destinazione

Per esempio, si può fare una copia leggibile di un CD-ROM, innestato nella directory /mnt/cdrom/, copiando i dati nella directory /tmp/cdrom/ (che viene creata automaticamente):

mkzftree -u /mnt/cdrom /tmp/cdrom[Invio]

Maggiori dettagli sull'uso di mkzftree si possono leggere nella pagina di manuale mkzftree(1).


1) Cloop   GNU GPL

2) Squashfs   GNU GPL

3) Cramfs   GNU GPL

4) Zisofs-tools   GNU GPL


Appunti di informatica libera 2008 --- Copyright © 2000-2008 Daniele Giacomini -- <appunti2 (ad) gmail·com>


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome file_160_system_compressi.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home]

Valid ISO-HTML!

CSS validator!

Gjlg Metamotore e Web Directory