Filesystem Maintenance

[Giorgos Keramidas]

On 2006-05-01 12:37, Raoul <raoul at raoul.shacknet.nu> wrote:
> Ποτέ δεν με απασχόλησε το θέμα της συντήρησης ενός ext2/ext3 και xfs
> filesystem, τα οποία και χρησιμοποιώ.
>
> Χρειάζεται κάποια extra ενέργεια εκ μέρους του χρήστη, εκτός από τον
> έλεγχο που γίνεται κατά το boot κάθε ν φορές που ένα partition έχει
> γίνει mounted (το ν ξέρω ότι μπορεί να καθοριστεί με το tune2fs για
> ext2/ext3)?

Υπάρχει η έννοια του 'fragmentation' και σε ένα UNIX filesystem, αλλά
όχι όπως ισχύει αυτή σε ένα FAT-based filesystem.

Εξαιτίας του τρόπου με τον οποίο δουλεύει το FAT, ένα αρχείο είναι μια
λίστα από 'περιοχές'.  Αυτή η λίστα γράφεται στο δίσκο με εξαιρετικά
απλοϊκή λογική, κι έτσι μπορεί ένα αρχείο να καταλήξει να έχει clusters
από δεδομένα με ιδιαίτερα χαζό τρόπο, όπως:

        ..712.56..38...

όπου η σειρά των data blocks ενός μόνο αρχείου είναι εντελώς 'τυχαία'.

Γι αυτό ένα FAT-based filesystem έχει συχνά ανάγκη από defrag, ώστε να
γραφτεί πάλι κάπως έτσι:

        ..12345....678..

ή έστω όσο το δυνατόν πιο κοντά σε μια μορφή σαν αυτή:

        ..12345678......

Σε ένα FAT filesystem όταν πειράξεις δεδομένα "στη μέση" ενός αρχείου,
το πιο πιθανό είναι το αρχείο στο πρώτο 'save' να καταλήξει πάλι κάπως
έτσι όμως:

        ..1234.789.56...

όπου τα blocks έχουν αλλάξει αρίθμηση και είναι πάλι "τυχαία" γραμμένα,
επειδή το block 5 άλλαξε και το block 6 είναι καινούριο.

Όλα αυτά δεν ισχύουν σε ένα ext2 filesystem και σε άλλα UNIX
filesystems, αφού σε αυτά ο δίσκος χωρίζεται σε "ομάδες" από blocks και
τα δεδομένα ενός αρχείου γεμίζουν, αν είναι δυνατόν, πρώτα μια ομάδα,
ύστερα τουλάχιστον ένα block από μια άλλη ομάδα κι ύστερα ένα μέρος από
ένα τελευταίο block.

Π.χ. το ίδιο αρχείο θα γραφόταν κάπως έτσι:

        AAAABBBBCCCCDDDD    (A, B, C, D = ομαδες από blocks)
        1234....5678....

κι όταν κάποιο πρόγραμμα το 'αντιγράψει' καθώς σώζει μια αλλαγή στη μέση
του αρχείου, αυτό θα γίνει:

        AAAABBBBCCCCDDDD
        1234....9...5678

Το γεγονός ότι πάλι δεν είναι σε συνεχόμενες ομάδες τα blocks δεν είναι
πρόβλημα, επειδή οποιοδήποτε data block του αρχείου μπορεί να
προσπελαστεί με πιο έξυπνο και γρήγορο τρόπο από μια απλή λίστα blocks
(την οποία πρέπει να διατρέξεις *κάθε* φορά από την αρχή για να βρείς το
block K).

Ακόμα καλύτερα, τα data blocks, ένα UNIX filesystem τα χωρίσει σε
μικρότερα κομμάτια, λεγόμενα 'fragments'.  Αυτά δεν έχουν σχέση με τα
'fragments' (περιοχές) ενός FAT αρχείου.  Είναι απλά ένας τρόπος να
εκμεταλλευτεί το UNIX τα μέρη ενός block που θα έμεναν αχρησιμοποιήτα αν
π.χ. το block size ήταν 8192 bytes κι εσύ έγραφες ένα αρχείο με μόνο 1
KB δεδομένα.

Ο τρόπος με τον οποίο δεσμεύονται blocks & fragments σε ένα UNIX fs
εξασφαλίζει ότι ένα αρχείο θα έχει:

    * ένα fragment

    * τουλάχιστον ένα ολόκληρο block και μηδέν ή ένα fragment

    * τουλάχιστον μια ομάδα blocks και μηδέν ή ένα fragment

    * τουλάχιστον μια ομάδα blocks, ένα ή περισσότερα ολόκληρα blocks
      και μηδέν ή περισσότερα fragments

Ετσι ποτέ ένα αρχείο δε θα έχει, π.χ., τη μορφή:

    CCCFB		(C = block cluster, B = block, F = fragment)

ή τη μορφή:

    BCCF

Επειδή τα UNIX filesystems είναι σχεδιασμένα να τοποθετούν τα data
blocks με 'καλό' τρόπο για τις επόμενες προσπελάσεις ενός αρχείου, αυτό
σημαίνει ότι το 'defragmentation' γίνεται (ξεχωριστά για κάθε αρχείο)
αυτόματα κάθε φορά που αντιγράφεις ένα αρχείο και σβήνεις το παλιό
αντίγραφο.

[ Περισσότερα εδώ: http://en.wikipedia.org/wiki/Unix_File_System ]

Αυτό έχει ως συνέπεια να μπορείς να 'επιταχύνεις' κάπως ένα UNIX
filesystem που χρησιμοποιείται πολύ καιρό κάνοντας απλά backup & restore
το filesystem!  Χωρίς όμως αυτό να είναι αναγκαστικό ή κάτι που πρέπει
να βάλεις στο πρόγραμμα να κάνεις, ας πούμε, μια φορά το μήνα ή το
χρόνο.

Αυτό είναι σχετικά εύκολο να το προγραμματίσεις.  Εγώ, για παράδειγμα,
περίπου μια φορά κάθε 2 χρόνια μεγαλώνω το μέγεθος του βασικού δίσκου.
Κάθε φορά που αλλάζω δίσκο, μεταφέρω τα αρχεία στον μεγαλύτερο.  Το
tar/untar κάνει ακριβώς μια αντιγραφή των αρχείων σε ένα νέο μέρος,
δίνοντας έτσι την ευκαιρία στο UFS να δεσμεύσει data blocks με τον πιο
καλό τρόπο που μπορεί εκείνη τη στιγμή, μειώνοντας σχετικά το
block fragmentation.