Ο πυρήνας Linux 6.2 θα περιλαμβάνει βελτιώσεις στο RAID5/6 στο Btrfs

Προτείνονται βελτιώσεις Btrfs για συμπερίληψη στον πυρήνα Linux 6.2 για την επίλυση του ζητήματος "write hole" στην υλοποίηση RAID 5/6. Η ουσία του προβλήματος συνοψίζεται στο γεγονός ότι εάν συνέβη μια συντριβή κατά την εγγραφή, είναι αρχικά αδύνατο να καταλάβουμε ποιο μπλοκ σε ποια από τις συσκευές RAID γράφτηκε σωστά και σε ποια η εγγραφή δεν ολοκληρώθηκε. Εάν επιχειρήσετε να δημιουργήσετε ξανά ένα RAID σε αυτήν την περίπτωση, τα μπλοκ που αντιστοιχούν σε μπλοκ που έχουν εγγραφεί μπορεί να είναι κατεστραμμένα επειδή η κατάσταση των μπλοκ RAID δεν είναι συγχρονισμένη. Αυτό το πρόβλημα παρουσιάζεται σε οποιεσδήποτε συστοιχίες RAID1/5/6 όπου δεν λαμβάνονται ειδικά μέτρα για την καταπολέμηση αυτού του φαινομένου.

Σε μια υλοποίηση RAID όπως το RAID1 σε btrfs, αυτό το πρόβλημα επιλύεται χρησιμοποιώντας αθροίσματα ελέγχου και στα δύο αντίγραφα, εάν υπάρχει αναντιστοιχία, τα δεδομένα απλώς αποκαθίστανται από το δεύτερο αντίγραφο. Αυτή η προσέγγιση λειτουργεί επίσης εάν κάποια συσκευή αρχίσει να δίνει λανθασμένα δεδομένα αντί για πλήρη αποτυχία.

Ωστόσο, στην περίπτωση του RAID5/6, το σύστημα αρχείων δεν αποθηκεύει αθροίσματα ελέγχου για μπλοκ ισοτιμίας: σε μια κανονική κατάσταση, η ορθότητα των μπλοκ ελέγχεται από το γεγονός ότι είναι όλα εξοπλισμένα με άθροισμα ελέγχου και το μπλοκ ισοτιμίας μπορεί να να αναδημιουργηθεί από τα δεδομένα. Ωστόσο, στην περίπτωση μερικής εγγραφής, αυτή η προσέγγιση ενδέχεται να μην λειτουργεί σε ορισμένες περιπτώσεις. Σε αυτήν την περίπτωση, κατά την επαναφορά του πίνακα, είναι πιθανό τα μπλοκ που έπεσαν κάτω από την ημιτελή εγγραφή να αποκατασταθούν εσφαλμένα.

Στην περίπτωση των btrfs, αυτό το πρόβλημα είναι πιο σχετικό εάν η εγγραφή που παράγεται είναι μικρότερη από τη λωρίδα. Σε αυτήν την περίπτωση, το σύστημα αρχείων πρέπει να εκτελέσει μια λειτουργία ανάγνωσης-τροποποίησης-εγγραφής (RMW). Εάν συναντήσει μπλοκ εγγραφής σε εξέλιξη, τότε η λειτουργία RMW μπορεί να προκαλέσει βλάβες που δεν θα εντοπιστούν, ανεξάρτητα από τα αθροίσματα ελέγχου. Οι προγραμματιστές έχουν κάνει αλλαγές στις οποίες η λειτουργία RMW ελέγχει το άθροισμα ελέγχου των μπλοκ πριν από την εκτέλεση αυτής της λειτουργίας και, εάν είναι απαραίτητο, η ανάκτηση δεδομένων εκτελεί επίσης έλεγχο αθροίσματος ελέγχου μετά την εγγραφή. Δυστυχώς, σε μια κατάσταση με την εγγραφή μιας ημιτελούς λωρίδας (RMW), αυτό οδηγεί σε επιπλέον επιβάρυνση για τον υπολογισμό των αθροισμάτων ελέγχου, αλλά αυξάνει σημαντικά την αξιοπιστία. Για το RAID6, αυτή η λογική δεν είναι ακόμη έτοιμη, ωστόσο, για μια τέτοια αποτυχία στο RAID6, είναι απαραίτητο η εγγραφή να αποτύχει σε 2 συσκευές ταυτόχρονα, κάτι που είναι λιγότερο πιθανό.

Επιπλέον, μπορούμε να σημειώσουμε τις συστάσεις για τη χρήση του RAID5 / 6 από τους προγραμματιστές, η ουσία των οποίων είναι ότι στο Btrfs το προφίλ για την αποθήκευση μεταδεδομένων και δεδομένων μπορεί να διαφέρει. Σε αυτήν την περίπτωση, μπορείτε να χρησιμοποιήσετε το προφίλ RAID1 (καθρέφτης) ή ακόμα και RAID1C3 (3 αντίγραφα) για μεταδεδομένα και RAID5 ή RAID6 για δεδομένα. Αυτό εξασφαλίζει αξιόπιστη προστασία των μεταδεδομένων και την απουσία «τρύπας εγγραφής», αφενός, και αποτελεσματικότερη χρήση του χώρου, τυπική για το RAID5/6, από την άλλη. Αυτό αποφεύγει τη διαφθορά στα μεταδεδομένα και η καταστροφή δεδομένων μπορεί να διορθωθεί.

Μπορεί επίσης να σημειωθεί ότι για SSD σε Btrfs στον πυρήνα 6.2, η ασύγχρονη εκτέλεση της λειτουργίας "απόρριψη" (επισήμανση ελευθέρων μπλοκ που δεν μπορούν πλέον να αποθηκευτούν φυσικά) θα ενεργοποιηθεί από προεπιλογή. Το πλεονέκτημα αυτής της λειτουργίας είναι η υψηλή απόδοση λόγω της αποτελεσματικής ομαδοποίησης των λειτουργιών "απόρριψης" σε μια ουρά και περαιτέρω επεξεργασία της ουράς από έναν χειριστή φόντου, λόγω του οποίου οι κανονικές λειτουργίες FS δεν επιβραδύνονται, όπως συμβαίνει με το σύγχρονο " απόρριψη" καθώς τα μπλοκ απελευθερώνονται και ο SSD μπορεί να πάρει καλύτερες αποφάσεις. Από την άλλη πλευρά, δεν θα χρειάζεται πλέον να χρησιμοποιείτε βοηθητικά προγράμματα όπως το fstrim, καθώς όλα τα διαθέσιμα μπλοκ θα διαγραφούν στο FS χωρίς να απαιτείται επιπλέον σάρωση και χωρίς επιβράδυνση των λειτουργιών.

Πηγή: opennet.ru

Προσθέστε ένα σχόλιο