όταν οι δίσκοι κάνουν σιωπηλά λάθη τι μας σώζει?

[Apollon Koutlidis]

  On 15/09/10 09:14, Apollon Oikonomopoulos wrote:
> On 10:35 Wed 15 Sep     , Γιώργος Πάλλας wrote:
>> On 09/15/2010 09:43 AM, Nick Demou wrote:
>>> 2010/9/15<rouvas at di.uoa.gr>:
>>>
>>>> Nick Demou wrote:
>>>>
>>>>> διάβασα πάρα-πολύ από χθες και όλα δείχνουν ότι [το btrfs] είναι σταθερό
>>>>> τουλάχιστον για non-critical δεδομένα. Προσωπικά θα το βάλω στα non
>>>>>
>>>> Αν τα δεδομένα σου είναι "non-critical", ποιος ο λόγος να ψάχνεις τόσο το
>>>> θέμα; on-line checksumming, RAID, κλπ;
>>>>
>>> έχω και critical και non-critical δεδομένα. Κάνω δοκιμές / πειράματα
>>> από νωρίς στα non-critical δεδομένα ώστε να μπορώ αργότερα να κάνω
>>> εφαρμογή όσων έμαθα στα critical. Τυπική στρατηγική.
>>>
>>>
>>>> Αν, πάλι, τα δεδομένα σου είναι "critical", η λύση είναι απλή και λέγεται
>>>> πολλαπλό back-up (αναλόγως πως αξιολογείς το "critical")
>>>>
>>
>> Νομίζω ότι είτε τα data είναι critical είτε όχι, πρέπει πάντα το state
>> τους να είναι ξεκάθαρο: είτε τα έχω, είτε όχι... Είχα δε την εντύπωση
>> ότι οι δίσκοι κάνουν checksumming (έστω υποτυπώδες) στα data blocks
>> τους. Κάνω λάθος;;
>>
> Κι όμως, πραγματικό end-to-end integrity υπάρχει μόνο στα μεγάλα
> enterprise storage systems (και εκεί συζητιέται…). Το πρόβλημα είναι
> διπλό:
>
> Αφενός τα filesystems που κάνουν checksumming (π.χ. btrfs) επαληθεύουν
> τα checksums κατά την ανάγνωση. Αν κάνεις πολύ καιρό να διαβάσεις τα
> δεδομένα σου ή να κάνεις fsck, μπορεί να αργήσεις να πάρεις είδηση ένα
> silent corruption που μπορεί να εξελίσσεται για μέρες ή και μήνες. Αυτός
> είναι ο λόγος που τα περισσότερα τέτοια filesystems έχουν και ένα
> background job που κάνει το λεγόμενο "scrubbing", διαβάζει και
> επαληθεύει δηλαδή τα δεδομένα που έχουν ήδη γραφτεί.
>
> Αφετέρου, κάθε layer (filesystem, OS, controller, δίσκος) κάνει checks
> για τον εαυτό του, χωρίς να υπάρχει ανταλλαγή πληροφοριών/parity με τα
> υπόλοιπα στρώματα. Γίνονται προσπάθειες για τυποποίηση ενός συστήματος
> (DIX - Data Integrity Extensions), το οποίο θα επιτρέπει την προσθήκη 8
> ακόμα bytes end-to-end (από το application layer μέχρι το δίσκο), τα
> οποία θα χρησιμοποιούνται για την επαλήθευση ότι τα δεδομένα που
> γράφτηκαν ήταν αυτά που ήθελε η εφαρμογή να γραφτούν (και όχι απλά αυτά
> που είπε ο controller να γραφτούν για παράδειγμα). Για όποιον
> ενδιαφέρεται για το ζήτημα, υπάρχει μια ενδιαφέρουσα παρουσίαση από το
> φετινό LinuxCon[1].
>
> Κοινώς, ο μόνος τρόπος να διασφαλίσει κανείς τα δεδομένα του είναι το
> τακτικό και πλήρες backup. Όταν και αν εφαρμοστεί στην πράξη το DIX,
> τότε θα μπορούμε να κοιμόμαστε χωρίς να βλέπουμε τόσο συχνά εφιάλτες με
> silent corruptions, αλλά backup και πάλι θα παίρνουμε.
>
> /Απόλλων
>
> [1] http://events.linuxfoundation.org/slides/2010/linuxcon2010_petersen.pdf

Υπάρχουν και άλλοι τρόποι να ασφαλίσεις την ακεραιότητα των δεδομένων 
σου. Η πλειοψηφία των περιπτώσεων corruption συμβαίνουν μεταξύ του write 
syscall και της μαγνητικής εγγραφής στο δίσκο - και εκεί είναι που το 
ZFS "δείχνει τα δόντια του", προσθέτοντας checksums τα οποία επαληθεύει 
στην επόμενη επανεγγραφή ή ανάγνωση. Κάπως συγκρίσιμα - αν και "ακριβά" 
- αποτελέσματα μπορεί να επιτύχει κανείς στήνοντας 3-way mirrors (δεν 
είναι ακόμα ξεκάθαρο κατά πόσο ένα RAID6 array επιτυγχάνει παρόμοια 
αποτελέσματα).

Κάνοντας περιοδικά checks στα mirrors σου (echo check > 
/sys/block/mdΧ/md/sync_action) και ελέγχοντας τα περιεχόμενα του 
mismatch_cnt (ls -1 /sys/block/md*/md/mismatch_cnt && cat 
/sys/block/md*/md/mismatch_cnt) βλέπεις εάν υπάρχουν "ασυμφωνίες" στο τι 
γράφτηκε στον καθένα, οπότε και ζητάς να γίνει αυτόματη "επισκευή" (echo 
repair > /sys/block/mdΧ/md/sync_action). Φυσικά σε κάθε βήμα 
παρακολουθείς τι λέει το /proc/mdstat για να ξέρεις πότε τελείωσε το 
κάθε βήμα.

Εάν έχεις μόνον δύο δίσκους στο mirror, είναι βασικά κορώνα / γράμματα. 
Αν έχεις πάνω από δύο, η πλειοψηφία θα θεωρηθεί ότι έχει δίκιο ως προς 
το ποια είναι τα "σωστά" δεδομένα. Το RedHat / CentOS 5 έχει "μαμίσιο" 
cron job που κάνει αυτό τον έλεγχο σε εβδομαδιαία βάση...

Η προσέγγιση αυτή έχει μπόλικα μειονεκτήματα (κόστος, μειωμένες 
επιδόσεις κατά τη διάρκεια του ελέγχου, αυξημένη κατανάλωση ρεύματος) 
αλλά τουλάχιστον σου δίνει κάποια παραπάνω βεβαιότητα ότι οι τσόντ^W^Wτα 
δεδομένα σου είναι (πιθανότατα) υγιή.

Εναλλακτικά, FreeBSD και ZFS :) το οποίο ούτε και αυτό είναι πανάκεια 
βέβαια αλλά ας μην αρχίσω τη γκρίνια.

Φιλικά,
Απόλλων