compressed volumes στο linux

[George Notaras]

On Tue, 2007-12-04 at 10:54 +0200, Christos Ricudis wrote:
> George Notaras wrote:
> > On Mon, 2007-12-03 at 18:03 +0200, George Notaras wrote:
> >   
> >> On Mon, 2007-12-03 at 11:13 +0200, George Notaras wrote:
> >>
> >>     
> >>> Μήπως είναι μπροστά μου και δεν το βλέπω?
> >>>       
> >> ...μάλλον.
> >>
> >> Στο site του cromfs έχει ένα διάφορες καλές πληροφορίες, όπως το
> >> παρακάτω feature comparison για μερικά compressed filesystems:
> >> http://bisqwit.iki.fi/source/cromfs.html#compare
> >>
> >> Καμιά πρόταση για κάποιο από αυτά?
> >>     
> >
> > Δυστυχώς πρόκειται για read-only filesystems. Πραγματικά σήμερα έχω
> > εκπλαγεί με το γεγονός ότι δεν υπάρχει κάποιο stable compressed
> > filesystem με read/write support.
> >
> > Ποιο είναι το πρόβλημα για κάτι τέτοιο?
> >   
> 
> Sxedon agnohse thn prohgoumenh erwthsh moy. Ayta pa8ainw otan grafw mail 
> prin piw kafe.

Φυσικά δεν σε παρεξηγώ. Δεν μπορεί να έχει κανείς τα πάντα στο μυαλό του
τη στιγμή που τα ζητάει κάποιος στη mailing list :) Αυτό δε συμβαίνει
ούτε στο πληρωμένο support! :)

> Apanthse sthn parakatw erwthsh :
> 
> Pws ylopoieitai to operation seek() se ena compressed file system? 
> Anaptykste thn apanthsh sas gia tis periptwseis block-level compression 
> kai file-level compression.
> 

Πριν αποό καιρό έτυχε να διαβάσω για μια υλοποίηση για random access σε
compressed data καθώς ασχολούμουν με το γράψιμο ενός dictionary server
σε python. Νομίζω ότι μπορώ να αντιληφθώ τη δυσκολία, όχι ακριβώς, αλλά
στο περίπου.

Παρακάτω δίνω ως παράδειγμα τι συμβαίνει με το με την "Random Access"
extension του gzip φορματ.

Δείτε το dictzip(1) (part of dictd)

Ο στόχος σε αυτή την περίπτωση είναι ο εξής:

Να συμπιεστεί ένα αρχείο κειμένου με έννοιες λέξεων, αλλά να μπορεί
κανείς να βρει γρήγορα την έννοια κάποιου λήμματος μέσα στο συμπιεσμένο
αρχείο.

Πώς υλοποιείται:

1) Τα δεδομένα (αρχείο με λήμματα και έννοιες) γίνονται indexed πριν
συμπιεστούν, δηλαδή το index είναι κάπως έτσι:

    ταβάνι 23445 230   (έννοια offset length)

2) Αφού συμπιεστούν CHLEN bytes δεδομένων (chunk), το μέγεθος σε bytes
του chunk που προκύπτει μετά τη συμπίεση καταγράφεται στο header του
gzip αρχείου.

3) Όταν επομένως θέλουμε την έννοια της λέξης "ταβάνι":

    α) Διαβάζεται το index για την έννοια "ταβάνι". Offset 23445 bytes
και length 230 (σε uncompressed data)
    β) Βρίσκουμε σε ποιο συμπιεσμένο chunk βρίσκονται τα παραπάνω data:
       πχ χονδρικά κάτι σαν 23445/CHLEN=Ν
    γ) Αποσυμπιέζεται το συγκεκριμένο chunk. Έχοντας το ζητούμενο εύρος
data σε uncompressed μορφή και γνωρίζοντας το μέγεθος των προηγούμενων
chunks επίσης σε uncompressed μορφή (N*CHLEN), μπορούμε να βρούμε το
ζητούμενο offset και να πάρουμε 230 bytes.

Ίσως να μην το έγραψα καλά, αλλά αν ασχοληθεί κανείς λίγο θα καταλάβει
πώς δουλεύει.

Το παραπάνω δείχνει αδρά τι μπορεί να συμβαίνει σε ένα read-only
compressed filesystem.

Αν υπήρχε και write support, δηλαδή αν μπορούσε κανείς να προσθέσει
έννοιες ή να συμπληρώσει ήδη υπάρχουσες, τότε δεν μπορώ να φανταστώ τι
είδους index θα χρειαζόταν και πόσο γρήγορη θα ήταν η όλη διαδικασία.