Δημοσιεύτηκε η δεύτερη συνέντευξη με τον Eduard Shishkin, προγραμματιστή του συστήματος αρχείων Reiser4.
Για αρχή, υπενθυμίστε στους αναγνώστες πού και για ποιον εργάζεστε.
Εργάζομαι ως κύριος αρχιτέκτονας αποθήκευσης στη Huawei Technologies, Γερμανικό Ερευνητικό Κέντρο. Στο τμήμα εικονικοποίησης ασχολούμαι με διάφορες πτυχές της αποθήκευσης δεδομένων. Οι δραστηριότητές μου δεν σχετίζονται με συγκεκριμένο λειτουργικό σύστημα.
Αυτήν τη στιγμή δεσμεύεστε στον κύριο κλάδο του πυρήνα;
Πολύ σπάνια και μόνο αν το ζητήσει ο εργοδότης μου. Η τελευταία φορά ήταν πριν από περίπου τρία χρόνια, έστειλα ενημερώσεις κώδικα για να αυξήσω την απόδοση αποθήκευσης που μοιράζομαι σε κεντρικούς υπολογιστές χρησιμοποιώντας το πρωτόκολλο 9p (άλλο όνομα για αυτήν την επιχείρηση είναι VirtFS). Εδώ πρέπει να σημειωθεί μια σημαντική σημείωση: αν και δουλεύω με το Linux εδώ και πολύ καιρό, δεν ήμουν ποτέ θαυμαστής του, δηλαδή «αναπνέω ομοιόμορφα», όπως με όλα τα άλλα. Συγκεκριμένα, αν παρατηρήσω κάποιο ελάττωμα, μπορώ να το επισημάνω το πολύ μια φορά. Και για να μπορέσετε στη συνέχεια να ακολουθήσετε κάποιον και να τον πείσετε - αυτό δεν θα συμβεί.
Θυμάμαι την τελευταία φορά, πριν από δέκα χρόνια, ήσασταν αρκετά επικριτικοί με το στυλ ανάπτυξης του πυρήνα. Από τη δική σας (ή ίσως εταιρική) σκοπιά, έχει αλλάξει κάτι, η κοινότητα ανταποκρίνεται περισσότερο ή όχι; Αν όχι, ποιος πιστεύεις ότι φταίει;
Δεν είδα ποτέ αλλαγές προς το καλύτερο. Το κύριο πρόβλημα της κοινότητας είναι η αντικατάσταση της επιστήμης με πολιτικές τεχνολογίες, προσωπικές σχέσεις, γνώμη της πλειοψηφίας, λαϊκισμός, συμβουλές από «εσωτερικές φωνές», σάπιοι συμβιβασμοί, οτιδήποτε άλλο εκτός από επιστήμη. Η επιστήμη των υπολογιστών, ό,τι και να πει κανείς, είναι πρώτα και κύρια μια ακριβής επιστήμη. Και αν κάποιος αρχίσει να διακηρύσσει τη δική του αξία για 2x2, διαφορετική από 4, κάτω από τη σημαία "Linux way" ή με κάποια άλλη σημαία, τότε αυτό είναι απίθανο να φέρει κάτι άλλο εκτός από κακό.
Όλα τα προβλήματα οφείλονται πρωτίστως στην ανικανότητα και την έλλειψη εκπαίδευσης όσων λαμβάνουν αποφάσεις. Εάν ένας διευθυντής είναι ανίκανος, δεν είναι σε θέση να λάβει μια αντικειμενική, επαρκή απόφαση. Αν είναι και ακαλλιέργητος, δεν μπορεί να βρει έναν ικανό ειδικό που θα του δώσει τις σωστές συμβουλές. Με μεγάλη πιθανότητα, η επιλογή θα πέσει σε έναν απατεώνα που λέει «φαινομενικά σωστά πράγματα». Ένα διεφθαρμένο περιβάλλον αναπτύσσεται πάντα γύρω από ανίκανους μοναχικούς ηγέτες. Επιπλέον, η ιστορία δεν γνωρίζει εξαιρέσεις από αυτή την άποψη, και η κοινότητα είναι η πιο ξεκάθαρη επιβεβαίωση αυτού.
Πώς αξιολογείτε την πρόοδο στην ανάπτυξη του Btrfs; Αυτό το FS απαλλάχθηκε από παιδικές ασθένειες; Πώς το τοποθετείτε για τον εαυτό σας - ως FS «για το σπίτι» ή και για εταιρική χρήση;
Δεν το ξεμπέρδεψα. Όλα όσα ανέφερα πριν από 11 χρόνια είναι επίκαιρα και σήμερα. Ένα από τα προβλήματα με το Btrfs που το καθιστά ακατάλληλο για σοβαρές ανάγκες είναι το πρόβλημα του ελεύθερου χώρου. Δεν μιλάω καν για το γεγονός ότι ο χρήστης καλείται να τρέξει στο κατάστημα για έναν νέο δίσκο σε περιπτώσεις όπου οποιοδήποτε άλλο FS θα έδειχνε πολύ ελεύθερο χώρο στο διαμέρισμα. Η αδυναμία ολοκλήρωσης μιας λειτουργίας σε λογικό όγκο λόγω έλλειψης ελεύθερου χώρου δεν είναι επίσης το χειρότερο. Το χειρότερο είναι ότι ένας μη προνομιούχος χρήστης μπορεί σχεδόν πάντα, να παρακάμψει τυχόν ποσοστώσεις δίσκου, να στερήσει από όλους ελεύθερο χώρο σε αρκετά σύντομο χρονικό διάστημα.
Μοιάζει με αυτό (δοκιμάστηκε για τον πυρήνα Linux 5.12). Ένα σενάριο εκκινείται σε ένα πρόσφατα εγκατεστημένο σύστημα, το οποίο σε ένα βρόχο δημιουργεί αρχεία με συγκεκριμένα ονόματα στον αρχικό κατάλογο, γράφει δεδομένα σε αυτά σε συγκεκριμένες μετατοπίσεις και στη συνέχεια διαγράφει αυτά τα αρχεία. Μετά από ένα λεπτό εκτέλεσης αυτού του σεναρίου, δεν συμβαίνει τίποτα ασυνήθιστο. Μετά από πέντε λεπτά, το τμήμα του κατειλημμένου χώρου στο διαμέρισμα αυξάνεται ελαφρώς. Μετά από δύο με τρεις ώρες φτάνει το 50% (με αρχική τιμή 15%). Και μετά από πέντε ή έξι ώρες εργασίας, το σενάριο κολλάει με το σφάλμα "δεν υπάρχει ελεύθερος χώρος στο διαμέρισμα". Μετά από αυτό, δεν μπορείτε πλέον να γράψετε ούτε ένα αρχείο 4K στο διαμέρισμα σας.
Παρουσιάζεται μια ενδιαφέρουσα κατάσταση: καταλήξατε να μην γράφετε τίποτα στο διαμέρισμα και όλος ο ελεύθερος χώρος (περίπου 85%) εξαφανίστηκε κάπου. Η ανάλυση μιας ενότητας που υπόκειται σε μια τέτοια επίθεση θα αποκαλύψει πολλούς κόμβους δέντρων που περιέχουν μόνο ένα στοιχείο (ένα αντικείμενο εξοπλισμένο με ένα κλειδί), σε μέγεθος πολλών byte. Δηλαδή, το περιεχόμενο που καταλάμβανε προηγουμένως το 15% του χώρου του δίσκου αποδείχθηκε ότι ήταν ομοιόμορφα "αλειμμένο" σε ολόκληρο το διαμέρισμα, έτσι ώστε να μην υπάρχει πού να γράψετε ένα νέο αρχείο, επειδή το κλειδί του είναι μεγαλύτερο από όλα τα υπάρχοντα και το δωρεάν τα μπλοκ στο διαμέρισμα έχουν τελειώσει.
Επιπλέον, όλα αυτά συμβαίνουν ήδη στη βασική διαμόρφωση Btrfs (χωρίς στιγμιότυπα, υποτόμους, κ.λπ.), και δεν έχει σημασία πώς αποφασίζετε να αποθηκεύσετε σώματα αρχείων σε αυτό το FS (ως "θραύσματα" σε ένα δέντρο ή ως εκτάσεις μη μορφοποιημένων μπλοκ) - το τελικό αποτέλεσμα θα είναι το ίδιο.
Δεν θα είστε σε θέση να υποβάλετε άλλα συστήματα αρχείων upstream σε μια τέτοια επίθεση (ό,τι κι αν σας λένε). Εξήγησα την αιτία του προβλήματος εδώ και πολύ καιρό: πρόκειται για μια πλήρη διαστροφή της έννοιας του δέντρου B στο Btrfs, που καθιστά δυνατό τον αυθόρμητο ή σκόπιμα εκφυλισμό του. Συγκεκριμένα, κάτω από ορισμένα φορτία, το σύστημα αρχείων σας θα "καταρρέει" συνεχώς κατά τη λειτουργία από μόνο του, χωρίς εξωτερική βοήθεια. Είναι σαφές ότι όλα τα είδη διαδικασιών παρασκηνίου «πατώντας» θα σώσουν τη μέρα μόνο σε μεμονωμένους επιτραπέζιους υπολογιστές.
Σε συλλογικούς διακομιστές, ένας εισβολέας θα μπορεί πάντα να τους "προηγείται". Ο διαχειριστής του συστήματος δεν θα μπορεί καν να προσδιορίσει ποιος ακριβώς τον εκφοβίζει. Ο πιο γρήγορος τρόπος για να διορθώσετε αυτό το πρόβλημα στο Btrfs είναι να επαναφέρετε τη δομή ενός κανονικού δέντρου B, δηλ. επανασχεδιάζοντας τη μορφή του δίσκου και ξαναγράφοντας σημαντικά τμήματα του κώδικα Btrfs. Αυτό θα διαρκέσει 8-10 χρόνια, συμπεριλαμβανομένου του εντοπισμού σφαλμάτων, υπό την προϋπόθεση ότι οι προγραμματιστές ακολούθησαν αυστηρά τα αρχικά άρθρα σχετικά με τους σχετικούς αλγόριθμους και δομές δεδομένων και δεν έπαιξαν το παιχνίδι "σπασμένου τηλεφώνου", όπως συνηθίζεται (και ενθαρρύνεται) στο "Linux". τρόπος".
Εδώ πρέπει επίσης να προσθέσουμε τον χρόνο που απαιτείται για να κατανοήσουν όλα αυτά οι προγραμματιστές. Εδώ είναι που γίνεται πιο δύσκολο. Σε κάθε περίπτωση, 10 χρόνια δεν ήταν αρκετά για να καταλάβουν. Λοιπόν, μέχρι τότε δεν μπορείτε να ελπίζετε σε ένα θαύμα. Δεν θα συμβεί με τη μορφή μιας επιλογής τοποθέτησης "για την οποία εσείς και εγώ δεν γνωρίζαμε", ή με τη μορφή μιας ενημέρωσης κώδικα που είναι "απλώς θέμα εργασίας" να προετοιμαστεί. Για κάθε τόσο βιαστική «διόρθωση» θα παρουσιάζω ένα νέο σενάριο εκφυλισμού. Τα B-trees είναι ένα από τα αγαπημένα μου θέματα και πρέπει να πω ότι αυτές οι δομές δεν ανέχονται τις ελευθερίες με τον εαυτό τους!
Πώς μπορώ να τοποθετήσω τα Btrfs για τον εαυτό μου; Ως κάτι που απολύτως δεν μπορεί να ονομαστεί σύστημα αρχείων, πόσο μάλλον να χρησιμοποιηθεί. Επειδή, εξ ορισμού, το FS είναι ένα υποσύστημα λειτουργικού συστήματος υπεύθυνο για την αποτελεσματική διαχείριση του πόρου «χώρου δίσκου», κάτι που δεν βλέπουμε στην περίπτωση του Btrfs. Λοιπόν, φαντάσου ότι ήρθες στο μαγαζί να αγοράσεις ρολόι για να μην αργήσεις στη δουλειά και αντί για ρολόι σου πούλησαν ηλεκτρική ψησταριά με χρονοδιακόπτη για 30 λεπτά το πολύ. Έτσι, η κατάσταση με το Btrfs είναι ακόμη χειρότερη.
Εξετάζοντας τις λίστες αλληλογραφίας, συναντώ συχνά τη δήλωση ότι η αποτελεσματική διαχείριση του χώρου στο δίσκο δεν είναι πλέον σχετική λόγω της φθηνής τιμής των μονάδων δίσκου. Αυτό είναι πλήρης ανοησία. Χωρίς έναν αποτελεσματικό διαχειριστή χώρου δίσκου, το λειτουργικό σύστημα θα γίνει ευάλωτο και άχρηστο. Ανεξάρτητα από τη χωρητικότητα των δίσκων στο μηχάνημά σας.
Θα ήθελα να ζητήσω ένα σχόλιο σχετικά με τη διακοπή της υποστήριξης Btrfs στην RHEL.
Δεν υπάρχει τίποτα ιδιαίτερο να σχολιάσω εδώ, όλα είναι πολύ ξεκάθαρα. Το είχαν επίσης ως "προεπισκόπηση τεχνολογίας". Έτσι, δεν πέρασα από αυτήν την ίδια την «προεπισκόπηση». Μην αφήσετε αυτή την ετικέτα να κρέμεται για πάντα! Αλλά δεν μπορούν να λανσάρουν ένα ελαττωματικό προϊόν υπο-σχεδιασμού με πλήρη υποστήριξη. Η RHEL είναι μια επιχείρηση, δηλαδή προδιαγεγραμμένες σχέσεις εμπορευμάτων-χρημάτων. Η Red Hat δεν μπορεί να εκφοβίσει τους χρήστες όπως κάνουν στη λίστα αλληλογραφίας Btrfs. Απλώς φανταστείτε την κατάσταση: ένας πελάτης που πλήρωσε τα χρήματα που κέρδισε με κόπο για το δίσκο και επίσης εσείς για υποστήριξη, θέλει να καταλάβει πού πήγε ο χώρος του στο δίσκο αφού δεν έγραψε τίποτα. Τι θα του απαντήσεις σε αυτό;
Περαιτέρω. Στους πελάτες της Red Hat περιλαμβάνονται γνωστές μεγάλες τράπεζες και χρηματιστήρια. Φανταστείτε τι θα συνέβαινε αν υπόκεινταν σε επιθέσεις DoS με βάση την αναφερόμενη ευπάθεια στο Btrfs. Ποιος πιστεύετε ότι ευθύνεται για αυτό; Σε όσους πρόκειται να κουνήσουν το δάχτυλό τους στη γραμμή της άδειας GPL, όπου γράφει ότι ο συγγραφέας δεν ευθύνεται για τίποτα, θα πω αμέσως: "κρύψτε το!" Το Red Hat θα απαντήσει, και με τέτοιο τρόπο που δεν θα φαίνεται αρκετό! Ξέρω όμως ότι η Red Hat δεν αντιμετωπίζει τέτοιου είδους πρόβλημα, δεδομένης της ιδιαίτερα ισχυρής ομάδας μηχανικών QA με τους οποίους είχα την ευκαιρία να συνεργαστώ στενά στην εποχή μου.
Γιατί ορισμένες εταιρείες συνεχίζουν να υποστηρίζουν τα Btrfs στα εταιρικά προϊόντα τους;
Λάβετε υπόψη σας ότι το πρόθεμα «enterprise» στο όνομα του προϊόντος δεν σημαίνει πολλά. Η επιχείρηση είναι ένα μέτρο ευθύνης που ενσωματώνεται στη συμβατική σχέση με τον πελάτη. Γνωρίζω μόνο μία επιχείρηση που βασίζεται στο GNU/Linux - RHEL. Όλα τα άλλα, κατά την άποψή μου, παρουσιάζονται μόνο ως επιχείρηση, αλλά δεν είναι ένα. Και τέλος, αν υπάρχει ζήτηση για κάτι, τότε θα υπάρχει πάντα προσφορά (στην περίπτωσή μας, αυτή είναι η αναφερόμενη «υποστήριξη»). Υπάρχει ζήτηση για απολύτως τα πάντα, συμπεριλαμβανομένων. και άχρηστο λογισμικό. Το πώς διαμορφώνεται μια τέτοια ζήτηση και ποιος την τροφοδοτεί είναι άλλο θέμα.
Επομένως, δεν θα βιαζόμουν να βγάλω συμπεράσματα αφού το Facebook φημολογείται ότι έχει αναπτύξει Btrfs στους διακομιστές του. Επιπλέον, θα συνιστούσα να κρατήσετε προσεκτικά τις διευθύνσεις αυτών των διακομιστών μυστικές για τους παραπάνω λόγους.
Γιατί έχει καταβληθεί τόση προσπάθεια για τον καθαρισμό του κώδικα XFS τελευταία; Εξάλλου, αρχικά πρόκειται για σύστημα αρχείων τρίτου κατασκευαστή και το ext4 είναι σταθερό εδώ και πολύ καιρό και έχει συνέχεια από προηγούμενες εξίσου σταθερές εκδόσεις. Τι ενδιαφέρον έχει η Red Hat για το XFS; Έχει νόημα να αναπτύξουμε ενεργά δύο συστήματα αρχείων που είναι παρόμοια ως προς τον σκοπό - ext4 και XFS;
Δεν θυμάμαι τι το οδήγησε σε αυτό. Είναι πολύ πιθανό ότι η πρωτοβουλία προήλθε από πελάτες της Red Hat. Θυμάμαι ότι διεξήχθη έρευνα αυτού του είδους: σε ορισμένα συστήματα αρχείων από το upstream, ένας τεράστιος αριθμός αντικειμένων δημιουργήθηκε σε μονάδες υψηλής τεχνολογίας της νέας γενιάς. Σύμφωνα με τα αποτελέσματα, το XFS συμπεριφέρθηκε καλύτερα από το ext4. Άρχισαν λοιπόν να το προβάλλουν ως το πιο πολλά υποσχόμενο. Σε κάθε περίπτωση, δεν θα έψαχνα κάτι συνταρακτικό εδώ.
Για μένα, είναι σαν να έχουν αντικαταστήσει ένα σουβλί με σαπούνι. Δεν έχει νόημα η ανάπτυξη ext4 και XFS. Τόσο παράλληλα όσο και οποιοδήποτε από αυτά για να διαλέξετε. Τίποτα καλό δεν θα βγει από αυτό. Αν και στη φύση υπάρχουν συχνά καταστάσεις όπου υπάρχουν πολλές δυνατότητες ανάπτυξης, αλλά δεν υπάρχει χώρος για ανάπτυξη. Σε αυτήν την περίπτωση, προκύπτουν διάφορες παράξενα άσχημες νέες αναπτύξεις, στις οποίες όλοι δείχνουν το δάχτυλο ("Ω, κοίτα, τι δεν θα δεις σε αυτή τη ζωή!").
Πιστεύετε ότι το ζήτημα της παραβίασης του επιπέδου έχει διευθετηθεί (με αρνητική έννοια) με την εμφάνιση των συναρτήσεων κρυπτογράφησης σε ext4, F2FS (για να μην αναφέρουμε το RAID στο Btrfs);
Γενικά, η εισαγωγή οποιωνδήποτε επιπέδων και η λήψη απόφασης για τη μη παραβίασή τους είναι συνήθως θέμα πολιτικής και δεν αναλαμβάνω να σχολιάσω κάτι εδώ. Οι αντικειμενικές πτυχές της παραβίασης επιπέδου δεν ενδιαφέρουν κανέναν, αλλά μπορούμε να εξετάσουμε μερικές από αυτές χρησιμοποιώντας το παράδειγμα της παραβίασης «από πάνω», δηλαδή την υλοποίηση στο FS της λειτουργικότητας που υπάρχει ήδη στο επίπεδο μπλοκ. Μια τέτοια «παραβίαση» δικαιολογείται με σπάνιες μόνο εξαιρέσεις. Για κάθε τέτοια περίπτωση, πρέπει πρώτα να αποδείξετε δύο πράγματα: ότι είναι πραγματικά απαραίτητο και ότι ο σχεδιασμός του συστήματος δεν θα βλάψει με αυτόν τον τρόπο.
Για παράδειγμα, ο κατοπτρισμός, που παραδοσιακά ήταν μια δραστηριότητα για το επίπεδο μπλοκ, είναι λογικό να εφαρμόζεται σε επίπεδο συστήματος αρχείων. Για διαφορετικούς λόγους. Για παράδειγμα, παρουσιάζεται καταστροφή δεδομένων "σιωπηλή" (σήψη bit) σε μονάδες δίσκου. Αυτό συμβαίνει όταν η συσκευή λειτουργεί σωστά, αλλά τα δεδομένα μπλοκ καταστρέφονται απροσδόκητα υπό την επίδραση ενός σκληρού κβαντικού γάμμα που εκπέμπεται από ένα μακρινό κβάζαρ κ.λπ. Το χειρότερο είναι αν αυτό το μπλοκ αποδειχθεί ότι είναι μπλοκ συστήματος FS (superblock, μπλοκ bitmap, κόμβος δέντρου αποθήκευσης, κ.λπ.), γιατί αυτό σίγουρα θα οδηγήσει σε πανικό πυρήνα.
Λάβετε υπόψη ότι οι καθρέφτες που προσφέρονται από το επίπεδο μπλοκ (το λεγόμενο RAID 1) δεν θα σας σώσουν από αυτό το πρόβλημα. Λοιπόν, αλήθεια: κάποιος πρέπει να ελέγξει τα αθροίσματα ελέγχου και να διαβάσει το αντίγραφο σε περίπτωση αποτυχίας; Επιπλέον, είναι λογικό να αντικατοπτρίζονται όχι μόνο τα πάντα, αλλά μόνο τα μεταδεδομένα. Ορισμένα σημαντικά δεδομένα (για παράδειγμα, εκτελέσιμα αρχεία κρίσιμων εφαρμογών) μπορούν να αποθηκευτούν ως μεταδεδομένα. Σε αυτή την περίπτωση, λαμβάνουν τις ίδιες εγγυήσεις ασφάλειας. Είναι λογικό να αναθέσουμε την προστασία των υπόλοιπων δεδομένων σε άλλα υποσυστήματα (ίσως και εφαρμογές χρηστών) - έχουμε παράσχει όλες τις απαραίτητες προϋποθέσεις για αυτό.
Τέτοιοι «οικονομικοί» καθρέφτες έχουν δικαίωμα ύπαρξης και μπορούν να οργανωθούν αποτελεσματικά μόνο σε επίπεδο συστήματος αρχείων. Διαφορετικά, η παραβίαση στρωσίματος γεμίζει ένα υποσύστημα με διπλό κώδικα για χάρη κάποιων μικροσκοπικών οφελών. Ένα εντυπωσιακό παράδειγμα αυτού είναι η υλοποίηση του RAID-5 με χρήση FS. Τέτοιες λύσεις (δικό τους RAID / LVM στο σύστημα αρχείων) σκοτώνουν το τελευταίο από αρχιτεκτονικούς όρους. Θα πρέπει επίσης να σημειωθεί εδώ ότι η παραβίαση του layering «τίθεται σε ροή» από διάφορα είδη απατεώνων μάρκετινγκ. Ελλείψει ιδεών, στα υποσυστήματα προστίθεται λειτουργικότητα που έχει εφαρμοστεί από καιρό σε γειτονικά επίπεδα, παρουσιάζεται ως ένα νέο εξαιρετικά χρήσιμο χαρακτηριστικό και προωθείται ενεργά.
Ο Reiser4 κατηγορήθηκε ότι παραβίασε τα επίπεδα «από κάτω». Με βάση το γεγονός ότι το σύστημα αρχείων δεν είναι μονολιθικό, όπως όλα τα άλλα, αλλά αρθρωτό, έγινε μια αβάσιμη υπόθεση ότι κάνει αυτό που θα έπρεπε να κάνει το παραπάνω επίπεδο (VFS).
Είναι δυνατόν να μιλήσουμε για τον θάνατο του ReiserFS v3.6 και, για παράδειγμα, του JFS; Τον τελευταίο καιρό δεν έχουν λάβει σχεδόν καμία προσοχή στον πυρήνα. Είναι ξεπερασμένα;
Εδώ πρέπει να ορίσουμε τι σημαίνει ο θάνατος ενός προϊόντος λογισμικού. Από τη μια πλευρά, χρησιμοποιούνται με επιτυχία (για αυτό δημιουργήθηκαν, τελικά), που σημαίνει ότι ζουν. Από την άλλη, δεν μπορώ να μιλήσω για το JFS (δεν ξέρω πολλά), αλλά το ReiserFS (v3) είναι πολύ δύσκολο να προσαρμοστεί στις νέες τάσεις (δοκιμασμένο στην πράξη). Αυτό σημαίνει ότι στο μέλλον οι προγραμματιστές θα δίνουν προσοχή όχι σε αυτό, αλλά σε αυτούς που είναι πιο εύκολο να προσαρμοστούν. Από αυτή την πλευρά αποδεικνύεται ότι, δυστυχώς, είναι νεκρό από αρχιτεκτονικούς όρους. Δεν θα χειραγωγούσα καθόλου την έννοια του «ηθικά απαρχαιωμένου». Ισχύει καλά, για παράδειγμα, σε μια ντουλάπα, αλλά όχι σε προϊόντα λογισμικού. Υπάρχει η έννοια της κατωτερότητας και της ανωτερότητας σε κάτι. Μπορώ να πω απολύτως ότι το ReserFS v3 είναι πλέον κατώτερο από το Reiser4 σε όλα, αλλά σε ορισμένους τύπους φόρτου εργασίας είναι ανώτερο από όλα τα άλλα upstream FS.
Γνωρίζετε για την ανάπτυξη των FS Tux3 και HAMMER/HAMMER2 (FS for DragonFly BSD);
Ναι, ξέρουμε. Στο Tux3 κάποτε με ενδιέφερε η τεχνολογία των στιγμιότυπων τους (οι λεγόμενοι «δείκτες έκδοσης»), αλλά στο Reiser4 πιθανότατα θα ακολουθήσουμε διαφορετική διαδρομή. Σκέφτομαι να υποστηρίξω στιγμιότυπα εδώ και πολύ καιρό και δεν έχω αποφασίσει ακόμη πώς να τα εφαρμόσω για απλούς τόμους Reiser4. Γεγονός είναι ότι η νέα "τεμπέλης" τεχνική μετρητή αναφοράς που προτείνεται από τον Ohad Rodeh λειτουργεί μόνο για B-trees. Δεν τους έχουμε. Για εκείνες τις δομές δεδομένων που χρησιμοποιούνται στο Reiesr4, δεν ορίζονται «τεμπέληδες» μετρητές - για την εισαγωγή τους, είναι απαραίτητο να λυθούν ορισμένα αλγοριθμικά προβλήματα, τα οποία κανείς δεν έχει αναλάβει ακόμη.
Σύμφωνα με το HAMMER: Διάβασα ένα άρθρο από τον δημιουργό. Δεν ενδιαφέρομαι. Και πάλι, Β-δέντρα. Αυτή η δομή δεδομένων είναι απελπιστικά ξεπερασμένη. Το εγκαταλείψαμε τον περασμένο αιώνα.
Πώς αξιολογείτε την αυξανόμενη ζήτηση για FS συμπλέγματος δικτύου όπως το CephFS/GlusterFS/κτλ; Σημαίνει αυτή η απαίτηση μετατόπιση των προτεραιοτήτων των προγραμματιστών προς το δίκτυο FS και ανεπαρκή προσοχή στο τοπικό FS;
Ναι, έχει συμβεί μια τέτοια αλλαγή προτεραιοτήτων. Η ανάπτυξη τοπικών συστημάτων αρχείων έχει μείνει στάσιμη. Δυστυχώς, το να κάνεις κάτι σημαντικό για τους τοπικούς όγκους είναι πλέον αρκετά δύσκολο και δεν μπορούν να το κάνουν όλοι. Κανείς δεν θέλει να επενδύσει στην ανάπτυξή τους. Αυτό είναι περίπου το ίδιο με το να ζητάτε από έναν εμπορικό οργανισμό να διαθέσει χρήματα για μαθηματική έρευνα - χωρίς κανένα ενθουσιασμό θα σας ρωτήσουν πώς μπορείτε να κερδίσετε χρήματα σε ένα νέο θεώρημα. Τώρα ένα τοπικό FS είναι κάτι που εμφανίζεται ως δια μαγείας "εκτός από το κουτί" και "πρέπει πάντα να λειτουργεί", και αν δεν λειτουργεί, προκαλεί ακατανόητη γκρίνια όπως: "Ναι, τι σκέφτονται!"
Εξ ου και η έλλειψη προσοχής στα τοπικά FS, αν και υπάρχει ακόμη πολλή δουλειά σε αυτόν τον τομέα. Και ναι, όλοι έχουν στραφεί στον κατανεμημένο χώρο αποθήκευσης, ο οποίος είναι χτισμένος με βάση ήδη υπάρχοντα τοπικά συστήματα αρχείων. Είναι πολύ της μόδας πλέον. Η φράση «Big Data» προκαλεί έκρηξη αδρεναλίνης σε πολλούς, συνδέοντάς τη με συνέδρια, εργαστήρια, μεγάλους μισθούς κ.λπ.
Πόσο λογικό είναι καταρχήν η εφαρμογή του συστήματος αρχείων δικτύου στο χώρο του πυρήνα και όχι στο χώρο του χρήστη;
Μια πολύ λογική προσέγγιση που δεν έχει ακόμα εφαρμοστεί πουθενά. Γενικά, το ερώτημα σε ποιο χώρο θα πρέπει να υλοποιηθεί ένα σύστημα αρχείων δικτύου είναι ένα «δίκοπο μαχαίρι». Λοιπόν, ας δούμε ένα παράδειγμα. Ο πελάτης κατέγραψε δεδομένα σε απομακρυσμένο μηχάνημα. Έπεσαν στην κρυφή μνήμη της σελίδας της με τη μορφή βρώμικων σελίδων. Αυτή είναι η δουλειά για ένα σύστημα αρχείων δικτύου "thin gateway" στο χώρο του πυρήνα. Τότε το λειτουργικό σύστημα αργά ή γρήγορα θα σας ζητήσει να γράψετε αυτές τις σελίδες στο δίσκο για να τις ελευθερώσετε. Στη συνέχεια, η μονάδα IO-forwarding (αποστολής) FS δικτύου μπαίνει σε λειτουργία. Καθορίζει σε ποιο μηχάνημα διακομιστή (κόμβος διακομιστή) θα πάνε αυτές οι σελίδες.
Στη συνέχεια, η στοίβα δικτύου αναλαμβάνει (και, όπως γνωρίζουμε, υλοποιείται στον χώρο του πυρήνα). Στη συνέχεια, ο κόμβος διακομιστή λαμβάνει αυτό το πακέτο με δεδομένα ή μεταδεδομένα και δίνει εντολή στη μονάδα αποθήκευσης backend (δηλαδή, το τοπικό FS που λειτουργεί στον χώρο του πυρήνα) να καταγράψει όλο αυτό το υλικό. Έτσι, περιορίσαμε το ερώτημα στο πού πρέπει να λειτουργούν οι ενότητες «αποστολής» και «λήψης». Εάν κάποια από αυτές τις λειτουργικές μονάδες εκτελείται στο χώρο χρήστη, αυτό αναπόφευκτα θα οδηγήσει σε εναλλαγή περιβάλλοντος (λόγω της ανάγκης χρήσης υπηρεσιών πυρήνα). Ο αριθμός τέτοιων διακοπτών εξαρτάται από τις λεπτομέρειες υλοποίησης.
Εάν υπάρχουν πολλοί τέτοιοι διακόπτες, τότε η απόδοση αποθήκευσης (απόδοση I/O) θα μειωθεί. Εάν η αποθήκευση του backend σας αποτελείται από αργούς δίσκους, τότε δεν θα παρατηρήσετε σημαντική πτώση. Αλλά εάν έχετε γρήγορους δίσκους (SSD, NVRAM, κ.λπ.), τότε η εναλλαγή περιβάλλοντος γίνεται ήδη «συμφόρηση» και, εξοικονομώντας την εναλλαγή περιβάλλοντος, η απόδοση μπορεί να αυξηθεί σημαντικά. Ο τυπικός τρόπος εξοικονόμησης χρημάτων είναι να μετακινήσετε μονάδες στο χώρο του πυρήνα. Για παράδειγμα, διαπιστώσαμε ότι η μετακίνηση του διακομιστή 9p από το QEMU στον πυρήνα του υπολογιστή κεντρικού υπολογιστή οδηγεί σε τριπλάσια αύξηση της απόδοσης του VirtFS.
Αυτό, φυσικά, δεν είναι ένα FS δικτύου, αλλά αντικατοπτρίζει πλήρως την ουσία των πραγμάτων. Το μειονέκτημα αυτής της βελτιστοποίησης είναι τα ζητήματα φορητότητας. Για κάποιους, το τελευταίο μπορεί να είναι κρίσιμο. Για παράδειγμα, το GlusterFS δεν έχει καθόλου modules στον πυρήνα. Χάρη σε αυτό, λειτουργεί πλέον σε πολλές πλατφόρμες, συμπεριλαμβανομένου του NetBSD.
Ποιες έννοιες θα μπορούσαν να δανειστούν τα τοπικά FS από τα δικτυακά και το αντίστροφο;
Σήμερα, τα FS δικτύου, κατά κανόνα, έχουν πρόσθετα σε τοπικά FS, οπότε δεν καταλαβαίνω ακριβώς πώς μπορείτε να δανειστείτε κάτι από τα τελευταία. Λοιπόν, πράγματι, ας σκεφτούμε μια εταιρεία 4 υπαλλήλων, στην οποία ο καθένας κάνει τα δικά του: ο ένας διανέμει, ο άλλος στέλνει, ο τρίτος λαμβάνει, ο τέταρτος αποθηκεύει. Και η ερώτηση, τι μπορεί να δανειστεί η εταιρεία από τον υπάλληλο της που την αποθηκεύει, ακούγεται κάπως λανθασμένη (έχει ήδη ό,τι θα μπορούσε να έχει δανειστεί από αυτόν εδώ και πολύ καιρό).
Αλλά τα τοπικά FS έχουν πολλά να μάθουν από τα δικτυακά. Πρώτον, θα πρέπει να μάθετε από αυτούς πώς να συγκεντρώνετε λογικούς όγκους σε υψηλό επίπεδο. Τώρα το λεγόμενο Τα «προηγμένα» τοπικά συστήματα αρχείων συγκεντρώνουν λογικούς τόμους αποκλειστικά χρησιμοποιώντας τεχνολογία «εικονικής συσκευής» δανεισμένη από το LVM (αυτή η ίδια μολυσματική παραβίαση στρωσίματος που εφαρμόστηκε για πρώτη φορά στο ZFS). Με άλλα λόγια, η μετάφραση εικονικών διευθύνσεων (αριθμοί μπλοκ) σε πραγματικές και αντίστροφα γίνεται σε χαμηλό επίπεδο (δηλαδή, αφού το σύστημα αρχείων έχει εκδώσει ένα αίτημα I/O).
Λάβετε υπόψη ότι η προσθήκη και η αφαίρεση συσκευών σε λογικούς τόμους (όχι κατόπτρες) που είναι διατεταγμένοι στο στρώμα μπλοκ οδηγεί σε προβλήματα για τα οποία οι προμηθευτές τέτοιων «χαρακτηριστικών» σιωπούν συγκρατημένα. Μιλάω για κατακερματισμό σε πραγματικές συσκευές, οι οποίες μπορούν να φτάσουν σε τερατώδεις τιμές, ενώ σε μια εικονική συσκευή όλα είναι καλά. Ωστόσο, λίγοι άνθρωποι ενδιαφέρονται για τις εικονικές συσκευές: όλοι ενδιαφέρονται για το τι συμβαίνει στις πραγματικές συσκευές σας. Ωστόσο, τα FS παρόμοια με το ZFS (καθώς και οποιοδήποτε FS σε συνδυασμό με το LVM) λειτουργούν μόνο με συσκευές εικονικού δίσκου (να εκχωρήσετε διευθύνσεις εικονικών δίσκων μεταξύ των ελεύθερων, να ανασυγκροτήσετε αυτές τις εικονικές συσκευές κ.λπ.). Και δεν έχουν ιδέα τι συμβαίνει σε πραγματικές συσκευές!
Τώρα φανταστείτε ότι έχετε μηδενικό κατακερματισμό στην εικονική συσκευή (δηλαδή, έχετε μόνο μια τεράστια έκταση που μένει εκεί), προσθέτετε έναν δίσκο στον λογικό τόμο σας και, στη συνέχεια, αφαιρείτε έναν άλλο τυχαίο δίσκο από τον λογικό σας τόμο και, στη συνέχεια, κάνετε επανεξισορρόπηση. Και τόσες φορές. Δεν είναι δύσκολο να φανταστεί κανείς ότι στην εικονική συσκευή θα εξακολουθείτε να έχετε τον ίδιο βαθμό ζωής, αλλά σε πραγματικές συσκευές δεν θα δείτε τίποτα καλό.
Το χειρότερο είναι ότι δεν μπορείτε καν να διορθώσετε αυτή την κατάσταση! Το μόνο πράγμα που μπορείτε να κάνετε εδώ είναι να ζητήσετε από το σύστημα αρχείων να ανασυγκροτήσει την εικονική συσκευή. Αλλά θα σας πει ότι όλα είναι υπέροχα εκεί - υπάρχει μόνο ένας βαθμός, ο κατακερματισμός είναι μηδέν και δεν μπορεί να είναι καλύτερο! Έτσι, οι λογικοί όγκοι που είναι διατεταγμένοι σε επίπεδο μπλοκ δεν προορίζονται για επαναλαμβανόμενη προσθήκη/αφαίρεση συσκευών. Με την καλή έννοια, χρειάζεται μόνο μια φορά να συναρμολογήσετε έναν λογικό τόμο σε επίπεδο μπλοκ, να τον δώσετε στο σύστημα αρχείων και μετά να μην κάνετε τίποτα άλλο με αυτόν.
Επιπλέον, ο συνδυασμός ανεξάρτητων υποσυστημάτων FS+LVM δεν επιτρέπει τη συνεκτίμηση της διαφορετικής φύσης των μονάδων δίσκου από τους οποίους συγκεντρώνονται οι λογικοί όγκοι. Πράγματι, ας υποθέσουμε ότι έχετε συναρμολογήσει έναν λογικό τόμο από HDD και συσκευές στερεάς κατάστασης. Αλλά τότε το πρώτο θα απαιτήσει ανασυγκρότηση, και το δεύτερο όχι. Για το δεύτερο, πρέπει να εκδώσετε αιτήματα απόρριψης, αλλά για τα πρώτα, όχι κ.λπ. Ωστόσο, σε αυτόν τον συνδυασμό είναι αρκετά δύσκολο να επιδειχθεί τέτοια επιλεκτικότητα.
Σημειώστε ότι αφού δημιουργήσετε το δικό σας LVM στο σύστημα αρχείων, η κατάσταση δεν βελτιώνεται πολύ. Επιπλέον, κάνοντας αυτό στην πραγματικότητα βάζετε τέλος στην προοπτική να το βελτιώσετε ποτέ στο μέλλον. Αυτό είναι πολύ κακό. Διαφορετικοί τύποι μονάδων δίσκου μπορούν να λειτουργούν στο ίδιο μηχάνημα. Και αν το σύστημα αρχείων δεν κάνει διάκριση μεταξύ τους, τότε ποιος θα το κάνει;
Ένα άλλο πρόβλημα περιμένει το λεγόμενο. Συστήματα αρχείων "Write-Anywhere" (αυτό περιλαμβάνει επίσης το Reiser4, εάν καθορίσατε το κατάλληλο μοντέλο συναλλαγών κατά την προσάρτηση). Τέτοια συστήματα αρχείων πρέπει να παρέχουν εργαλεία ανασυγκρότησης που δεν έχουν προηγούμενο στη δύναμή τους. Και ο διαχειριστής έντασης ήχου χαμηλού επιπέδου δεν βοηθά εδώ, αλλά απλώς παρεμποδίζει. Το γεγονός είναι ότι με έναν τέτοιο διαχειριστή, το FS σας θα αποθηκεύσει έναν χάρτη με δωρεάν μπλοκ μόνο μιας συσκευής - μιας εικονικής. Κατά συνέπεια, μπορείτε να ανασυγκροτήσετε μόνο μια εικονική συσκευή. Αυτό σημαίνει ότι το πρόγραμμα ανασυγκρότησης θα λειτουργεί για μεγάλο χρονικό διάστημα σε έναν τεράστιο χώρο εικονικών διευθύνσεων.
Και αν έχετε πολλούς χρήστες που κάνουν τυχαίες αντικαταστάσεις, τότε το χρήσιμο αποτέλεσμα ενός τέτοιου ανασυγκροτητή θα μειωθεί στο μηδέν. Το σύστημά σας αναπόφευκτα θα αρχίσει να επιβραδύνεται και θα πρέπει μόνο να διπλώσετε τα χέρια σας μπροστά στην απογοητευτική διάγνωση «σπασμένο σχέδιο». Αρκετοί ανασυγκροτητές που εκτελούνται στον ίδιο χώρο διευθύνσεων θα παρεμβαίνουν μόνο μεταξύ τους. Είναι εντελώς διαφορετικό θέμα αν διατηρείτε τον δικό σας χάρτη με δωρεάν μπλοκ για κάθε πραγματική συσκευή. Αυτό θα παραλληλίσει αποτελεσματικά τη διαδικασία ανασυγκρότησης.
Αλλά αυτό μπορεί να γίνει μόνο εάν έχετε έναν υψηλού επιπέδου λογικό διαχειριστή τόμου. Τοπικά συστήματα αρχείων με τέτοιους διαχειριστές δεν υπήρχαν προηγουμένως (τουλάχιστον, δεν ξέρω για αυτούς). Μόνο τα συστήματα αρχείων δικτύου (για παράδειγμα GlusterFS) είχαν τέτοιους διαχειριστές. Ένα άλλο πολύ σημαντικό παράδειγμα είναι το βοηθητικό πρόγραμμα ελέγχου ακεραιότητας τόμου (fsck). Εάν αποθηκεύσετε τον δικό σας ανεξάρτητο χάρτη ελεύθερων μπλοκ για κάθε υποτόμο, τότε η διαδικασία για τον έλεγχο ενός λογικού τόμου μπορεί να παραλληλιστεί αποτελεσματικά. Με άλλα λόγια, οι λογικοί όγκοι με διευθυντές υψηλού επιπέδου κλιμακώνονται καλύτερα.
Επιπλέον, με τους διαχειριστές όγκου χαμηλού επιπέδου δεν θα μπορείτε να οργανώσετε ολοκληρωμένα στιγμιότυπα. Με συστήματα αρχείων τύπου LVM και ZFS, μπορείτε να τραβήξετε μόνο τοπικά στιγμιότυπα, αλλά όχι καθολικά στιγμιότυπα. Τα τοπικά στιγμιότυπα σάς επιτρέπουν να επαναφέρετε αμέσως μόνο τις κανονικές λειτουργίες αρχείων. Και κανείς εκεί δεν θα επαναφέρει τις λειτουργίες με λογικούς τόμους (προσθήκη/αφαίρεση συσκευών). Ας το δούμε αυτό με ένα παράδειγμα. Κάποια στιγμή, όταν έχετε έναν λογικό τόμο δύο συσκευών Α και Β που περιέχουν 100 αρχεία, τραβάτε ένα στιγμιότυπο του συστήματος S και στη συνέχεια δημιουργείτε άλλα εκατό αρχεία.
Μετά από αυτό, προσθέτετε τη συσκευή C στον τόμο σας και, τέλος, επαναφέρετε το σύστημά σας στο στιγμιότυπο S. Ερώτηση: Πόσα αρχεία και συσκευές περιέχει ο λογικός τόμος σας μετά την επαναφορά στο S; Θα υπάρχουν 100 αρχεία, όπως ίσως μαντέψατε, αλλά θα υπάρχουν 3 συσκευές - πρόκειται για τις ίδιες συσκευές A, B και C, αν και τη στιγμή που δημιουργήθηκε το στιγμιότυπο υπήρχαν μόνο δύο συσκευές στο σύστημα (Α και Β ). Η λειτουργία προσθήκης συσκευής C δεν επανήλθε και εάν αφαιρέσετε τώρα τη συσκευή C από τον υπολογιστή, θα καταστρέψει τα δεδομένα σας, επομένως πριν τη διαγράψετε θα πρέπει πρώτα να εκτελέσετε μια ακριβή λειτουργία για να αφαιρέσετε τη συσκευή από τον λογικό τόμο επανεξισορρόπησης, η οποία θα διασκορπίσει όλα τα δεδομένα από τη συσκευή C στις συσκευές Α και Β. Ωστόσο, εάν το FS σας υποστήριζε καθολικά στιγμιότυπα, δεν θα απαιτείται τέτοια επανεξισορρόπηση και μετά από μια άμεση επαναφορά στο S, μπορείτε να αφαιρέσετε με ασφάλεια τη συσκευή C από τον υπολογιστή.
Έτσι, τα καθολικά στιγμιότυπα είναι καλά γιατί σας επιτρέπουν να αποφύγετε την δαπανηρή αφαίρεση (προσθήκη) μιας συσκευής από έναν λογικό τόμο (σε έναν λογικό τόμο) με μεγάλο όγκο δεδομένων (φυσικά, αν θυμάστε να "στιγμιότυπετε" το σύστημά σας την κατάλληλη στιγμή). Να σας υπενθυμίσω ότι η δημιουργία στιγμιότυπων και η επαναφορά του συστήματος αρχείων σε αυτά είναι στιγμιαίες λειτουργίες. Μπορεί να προκύψει το ερώτημα: πώς είναι ακόμη δυνατό να επαναφέρετε αμέσως μια λειτουργία σε έναν λογικό τόμο που σας πήρε τρεις ημέρες; Αλλά είναι δυνατόν! Με την προϋπόθεση ότι το σύστημα αρχείων σας έχει σχεδιαστεί σωστά. Σκέφτηκα την ιδέα τέτοιων «3D στιγμιότυπων» πριν από τρία χρόνια και πέρυσι κατοχύρωσα αυτή την τεχνική με δίπλωμα ευρεσιτεχνίας.
Το επόμενο πράγμα που πρέπει να μάθουν τα τοπικά FS από τα δικτυακά είναι να αποθηκεύουν μεταδεδομένα σε ξεχωριστές συσκευές με τον ίδιο τρόπο που τα δικτυακά FS τα αποθηκεύουν σε ξεχωριστά μηχανήματα (τους λεγόμενους διακομιστές μεταδεδομένων). Υπάρχουν εφαρμογές που λειτουργούν κυρίως με μεταδεδομένα και αυτές οι εφαρμογές μπορούν να επιταχυνθούν σημαντικά τοποθετώντας τα μεταδεδομένα σε ακριβές συσκευές αποθήκευσης υψηλής απόδοσης. Με τον συνδυασμό FS+LVM, δεν θα μπορείτε να επιδείξετε τέτοια επιλεκτικότητα: το LVM δεν γνωρίζει τι υπάρχει στο μπλοκ που του μεταβιβάσατε (δεδομένα εκεί ή μεταδεδομένα).
Δεν θα ωφεληθείτε πολύ από την εφαρμογή του δικού σας LVM χαμηλού επιπέδου στο FS σε σύγκριση με τον συνδυασμό FS+LVM, αλλά αυτό που μπορείτε να κάνετε πολύ καλά είναι να ακαταστήσετε το FS έτσι ώστε αργότερα να καταστεί αδύνατο να εργαστείτε με τον κώδικά του. Το ZFS και το Btrfs, που έσπευσαν με εικονικές συσκευές, είναι όλα ξεκάθαρα παραδείγματα του τρόπου με τον οποίο η παραβίαση στρωμάτων σκοτώνει το σύστημα από αρχιτεκτονικούς όρους, λοιπόν, γιατί είμαι όλο αυτό; Επιπλέον, δεν χρειάζεται να δημιουργήσετε το δικό σας LVM χαμηλού επιπέδου στο σύστημα αρχείων. Αντίθετα, πρέπει να συγκεντρώσετε συσκευές σε λογικούς τόμους σε υψηλό επίπεδο, όπως κάνουν ορισμένα συστήματα αρχείων δικτύου με διαφορετικά μηχανήματα (κόμβοι αποθήκευσης). Είναι αλήθεια ότι το κάνουν αυτό αηδιαστικά λόγω της χρήσης κακών αλγορίθμων.
Παραδείγματα απολύτως τρομερών αλγορίθμων είναι ο μεταφραστής DHT στο σύστημα αρχείων GlusterFS και ο λεγόμενος χάρτης CRUSH στο σύστημα αρχείων Ceph. Κανένας από τους αλγόριθμους που είδα δεν με ικανοποίησε όσον αφορά την απλότητα και την καλή επεκτασιμότητα. Έπρεπε λοιπόν να θυμηθώ την άλγεβρα και να εφεύρω τα πάντα μόνος μου. Το 2015, ενώ πειραματιζόμουν με πακέτα πάνω από λειτουργίες κατακερματισμού, κατέληξα και κατοχύρωσα με δίπλωμα ευρεσιτεχνίας κάτι που μου ταιριάζει. Τώρα μπορώ να πω ότι η προσπάθεια να γίνουν όλα αυτά πράξη ήταν επιτυχής. Δεν βλέπω κανένα πρόβλημα με την επεκτασιμότητα στη νέα προσέγγιση.
Ναι, κάθε υποτόμος θα απαιτεί μια ξεχωριστή δομή, όπως ένα superblock στη μνήμη. Είναι πολύ τρομακτικό αυτό; Γενικά, δεν ξέρω ποιος θα «βράσει τον ωκεανό» και θα δημιουργήσει λογικούς όγκους εκατοντάδων χιλιάδων ή περισσότερων συσκευών σε ένα τοπικό μηχάνημα. Αν μπορεί κάποιος να μου το εξηγήσει αυτό, θα είμαι πολύ ευγνώμων. Εν τω μεταξύ, για μένα αυτό είναι μαλακίες μάρκετινγκ.
Πώς επηρέασαν οι αλλαγές στο υποσύστημα συσκευών μπλοκ πυρήνα (για παράδειγμα, η εμφάνιση του blk-mq) τις απαιτήσεις για την υλοποίηση FS;
Δεν είχαν καμία επίδραση. Δεν ξέρω τι θα συνέβαινε στο στρώμα μπλοκ που θα καθιστούσε απαραίτητο τον σχεδιασμό ενός νέου FS. Η διεπαφή αλληλεπίδρασης αυτών των υποσυστημάτων είναι πολύ κακή. Από την πλευρά του προγράμματος οδήγησης, το FS θα πρέπει να επηρεάζεται μόνο από την εμφάνιση νέων τύπων μονάδων δίσκου, στους οποίους θα προσαρμοστεί πρώτα το επίπεδο μπλοκ και μετά το FS (για το reiser4 αυτό θα σημαίνει την εμφάνιση νέων προσθηκών).
Η εμφάνιση νέων τύπων μέσων (για παράδειγμα, SMR, ή η πανταχού παρουσία των SSD) σημαίνει θεμελιωδώς νέες προκλήσεις για το σχεδιασμό του συστήματος αρχείων;
Ναί. Και αυτά είναι κανονικά κίνητρα για την ανάπτυξη του FS. Οι προκλήσεις μπορεί να είναι διαφορετικές και εντελώς απροσδόκητες. Για παράδειγμα, έχω ακούσει για μονάδες δίσκου όπου η ταχύτητα μιας λειτουργίας I/O εξαρτάται σε μεγάλο βαθμό από το μέγεθος ενός τμήματος δεδομένων και τη μετατόπισή του. Στο Linux, όπου το μέγεθος του μπλοκ FS δεν μπορεί να υπερβαίνει το μέγεθος της σελίδας, μια τέτοια μονάδα δίσκου δεν θα εμφανίζει τις πλήρεις δυνατότητές της από προεπιλογή. Ωστόσο, εάν το σύστημα αρχείων σας έχει σχεδιαστεί σωστά, τότε υπάρχει πιθανότητα να αξιοποιήσετε πολύ περισσότερα από αυτό.
Πόσα άτομα εργάζονται αυτήν τη στιγμή με τον κωδικό Reiser4 εκτός από εσάς;
Λιγότερο από ό,τι θα ήθελα, αλλά δεν αντιμετωπίζω οξεία έλλειψη πόρων. Είμαι περισσότερο από ικανοποιημένος με τον ρυθμό ανάπτυξης του Reiser4. Δεν πρόκειται να "οδηγήσω άλογα" - αυτή δεν είναι η σωστή περιοχή. Εδώ, "αν οδηγείτε πιο ήσυχα, θα συνεχίσετε!" Ένα σύγχρονο σύστημα αρχείων είναι το πιο περίπλοκο υποσύστημα πυρήνα, οι λανθασμένες σχεδιαστικές αποφάσεις του οποίου μπορούν να αναιρέσουν τα επόμενα χρόνια ανθρώπινης εργασίας.
Προσφέροντας εθελοντές να υλοποιήσουν κάτι, εγγυώμαι πάντα ότι οι προσπάθειες θα οδηγήσουν σίγουρα στο σωστό αποτέλεσμα, το οποίο μπορεί να είναι ζητούμενο για σοβαρές ανάγκες. Όπως καταλαβαίνετε, δεν μπορούν να υπάρχουν πολλές τέτοιες εγγυήσεις ταυτόχρονα. Ταυτόχρονα, δεν αντέχω «φιγούρες» που προωθούν ξεδιάντροπα «χαρακτηριστικά» προφανώς άχρηστου λογισμικού, εξαπατώντας εκατοντάδες χρήστες και προγραμματιστές και ταυτόχρονα κάθονται και χαμογελούν σε σύνοδο κορυφής πυρήνα.
Έχει εκφράσει κάποια εταιρεία προθυμία να υποστηρίξει την ανάπτυξη του Reiser4;
Ναι, υπήρξαν τέτοιες προτάσεις, π.χ. και από μεγάλο πωλητή. Αλλά για αυτό έπρεπε να μετακομίσω σε άλλη χώρα. Δυστυχώς, δεν είμαι πια 30 χρονών, δεν μπορώ να ξεκολλήσω και να φύγω έτσι με το πρώτο σφύριγμα.
Ποια χαρακτηριστικά λείπουν αυτήν τη στιγμή από το Reiser4;
Δεν υπάρχει συνάρτηση "αλλαγή μεγέθους" για απλούς τόμους, παρόμοια με αυτή που βρίσκεται στο ReiserFS(v3). Επιπλέον, οι λειτουργίες αρχείων με τη σημαία DIRECT_IO δεν θα βλάψουν. Στη συνέχεια, θα ήθελα να μπορώ να διαχωρίσω έναν τόμο σε «σημασιολογικούς υποτόμους», οι οποίοι δεν έχουν σταθερό μέγεθος και οι οποίοι μπορούν να προσαρτηθούν ως ανεξάρτητοι τόμοι. Αυτά τα προβλήματα είναι καλά για αρχάριους που θέλουν να δοκιμάσουν τις δυνάμεις τους στο «πραγματικό πράγμα».
Και τέλος, θα ήθελα να έχω δικτυακούς λογικούς τόμους με απλή υλοποίηση και διαχείριση (οι σύγχρονοι αλγόριθμοι το επιτρέπουν ήδη). Αλλά αυτό που σίγουρα δεν θα έχει ποτέ το Reiser4 είναι το RAID-Z, τα scrubs, οι κρυφές μνήμες ελεύθερου χώρου, οι μεταβλητές 128-bit και άλλες ανοησίες μάρκετινγκ που προέκυψαν στο πλαίσιο της έλλειψης ιδεών μεταξύ των προγραμματιστών ορισμένων συστημάτων αρχείων.
Μπορούν όλα όσα μπορεί να χρειαστούν να υλοποιηθούν από πρόσθετα;
Αν μιλάμε μόνο με όρους διεπαφών και πρόσθετων (modules) που τα υλοποιούν, τότε όχι τα πάντα. Αλλά αν εισάγετε επίσης σχέσεις σε αυτές τις διεπαφές, τότε, μεταξύ άλλων, θα έχετε τις έννοιες των ανώτερων πολυμορφισμών, με τις οποίες μπορείτε ήδη να τα βγάλετε πέρα. Φανταστείτε ότι υποθετικά παγώσατε ένα αντικειμενοστρεφές σύστημα χρόνου εκτέλεσης, αλλάξατε την τιμή του δείκτη εντολών για να κατευθύνετε σε ένα άλλο πρόσθετο που υλοποιεί την ίδια διεπαφή X και, στη συνέχεια, ξεπαγώστε το σύστημα ώστε να συνεχίσει να εκτελείται.
Εάν ο τελικός χρήστης δεν παρατηρήσει μια τέτοια «υποκατάσταση», τότε λέμε ότι το σύστημα έχει πολυμορφισμό μηδενικής τάξης στη διεπαφή Χ (ή το σύστημα είναι ετερογενές στη διεπαφή Χ, που είναι το ίδιο πράγμα). Εάν τώρα όχι μόνο έχετε ένα σύνολο διεπαφών, αλλά έχετε και σχέσεις σε αυτές (γραφική παράσταση διεπαφής), τότε μπορείτε να εισαγάγετε πολυμορφισμούς υψηλότερων τάξεων, οι οποίοι θα χαρακτηρίζουν την ετερογένεια του συστήματος ήδη στη "γειτονιά" οποιασδήποτε διεπαφής. Έχω εισαγάγει μια τέτοια ταξινόμηση πριν από πολύ καιρό, αλλά, δυστυχώς, δεν συνέβη ποτέ.
Έτσι, με τη βοήθεια πρόσθετων και τέτοιων υψηλότερων πολυμορφισμών, μπορείτε να περιγράψετε οποιοδήποτε γνωστό χαρακτηριστικό, καθώς και να «προβλέψετε» εκείνα που δεν έχουν καν αναφερθεί ποτέ. Δεν μπόρεσα να το αποδείξω αυστηρά, αλλά δεν γνωρίζω ακόμη κάποιο αντιπαράδειγμα. Γενικά, αυτή η ερώτηση μου θύμισε το «Erlangen Program» του Felix Klein. Κάποτε προσπάθησε να αναπαραστήσει όλη τη γεωμετρία ως κλάδο της άλγεβρας (συγκεκριμένα, τη θεωρία ομάδων).
Τώρα στο κύριο ερώτημα - πώς πάνε τα πράγματα με την προώθηση του Reiser4 στον βασικό πυρήνα; Υπήρξαν δημοσιεύσεις σχετικά με την αρχιτεκτονική αυτού του συστήματος αρχείων για τις οποίες μιλήσατε στην τελευταία συνέντευξη; Πόσο επίκαιρη είναι αυτή η ερώτηση από την άποψή σας;
Γενικά εδώ και τρία χρόνια ζητάμε ένταξη στον κύριο κλάδο. Το τελευταίο σχόλιο του Reiser στο δημόσιο νήμα όπου έγινε το αίτημα έλξης παρέμεινε αναπάντητο. Επομένως, όλες οι περαιτέρω ερωτήσεις δεν είναι για εμάς. Προσωπικά δεν καταλαβαίνω γιατί πρέπει να "συγχωνευθούμε" σε ένα συγκεκριμένο λειτουργικό σύστημα. Στο Linux, το φως δεν συνέκλινε σαν σφήνα. Έτσι, υπάρχει ένα ξεχωριστό αποθετήριο στο οποίο θα υπάρχουν αρκετές θύρες υποκαταστημάτων για διαφορετικά λειτουργικά συστήματα. Όποιος το χρειάζεται μπορεί να κλωνοποιήσει την αντίστοιχη θύρα και να κάνει ό,τι θέλει με αυτό (εντός της άδειας φυσικά). Λοιπόν, αν κάποιος δεν το χρειάζεται, τότε δεν είναι δικό μου πρόβλημα. Σε αυτό το σημείο, προτείνω να εξετάσουμε το ζήτημα της «προώθησης στον κύριο πυρήνα του Linux» ως διευθετημένο.
Οι δημοσιεύσεις για την αρχιτεκτονική FS είναι σχετικές, αλλά μέχρι στιγμής έχω βρει χρόνο μόνο για τα νέα μου αποτελέσματα, τα οποία θεωρώ ότι είναι υψηλότερη προτεραιότητα. Ένα άλλο πράγμα είναι ότι είμαι μαθηματικός και στα μαθηματικά κάθε δημοσίευση είναι μια περίληψη θεωρημάτων και των αποδείξεών τους. Το να δημοσιεύεις οτιδήποτε εκεί χωρίς απόδειξη είναι σημάδι κακόγουστο. Εάν αποδείξω ή διαψεύσω επισταμένως οποιαδήποτε δήλωση σχετικά με την αρχιτεκτονική του FS, τότε το αποτέλεσμα θα είναι τέτοιοι σωροί που θα είναι αρκετά δύσκολο να ξεπεραστούν. Ποιος το χρειάζεται; Αυτός είναι πιθανώς ο λόγος που όλα συνεχίζουν να παραμένουν στην παλιά τους μορφή - ο πηγαίος κώδικας και τα σχόλια σε αυτό.
Τι νέο υπάρχει στο Reiser4 τα τελευταία χρόνια;
Η πολυαναμενόμενη σταθερότητα επιτέλους υλοποιήθηκε. Ένα από τα τελευταία που εμφανίστηκαν ήταν ένα σφάλμα που οδήγησε σε "μη διαγράψιμους" καταλόγους. Η δυσκολία ήταν ότι εμφανιζόταν μόνο στο φόντο των συγκρούσεων κατακερματισμού ονομάτων και με μια συγκεκριμένη θέση εγγραφών καταλόγου σε έναν κόμβο δέντρου. Ωστόσο, εξακολουθώ να μην μπορώ να προτείνω το Reiser4 για παραγωγή: για αυτό πρέπει να κάνετε κάποια εργασία με ενεργή αλληλεπίδραση με τους διαχειριστές συστημάτων παραγωγής.
Τελικά καταφέραμε να υλοποιήσουμε την μακροχρόνια ιδέα μας - διαφορετικά μοντέλα συναλλαγών. Προηγουμένως, το Reiser4 έτρεχε μόνο ένα μοντέλο Macdonald-Reiser με σκληρό κώδικα. Αυτό δημιούργησε προβλήματα σχεδιασμού. Ειδικότερα, τα στιγμιότυπα δεν είναι δυνατά σε ένα τέτοιο μοντέλο συναλλαγών - θα καταστραφούν από ένα ατομικό στοιχείο που ονομάζεται «ΣΥΝΟΛΟ ΑΝΤΙΓΡΑΨΗΣ». Το Reiser4 υποστηρίζει επί του παρόντος τρία μοντέλα συναλλαγών. Σε ένα από αυτά (Write-Anywhere), το ατομικό στοιχείο OVERWRITE SET περιλαμβάνει μόνο σελίδες συστήματος (εικόνες από bitmaps δίσκου κ.λπ.), οι οποίες δεν μπορούν να «φωτογραφηθούν» (το πρόβλημα με το κοτόπουλο και το αυγό).
Έτσι οι εικόνες μπορούν πλέον να πραγματοποιηθούν με τον καλύτερο δυνατό τρόπο. Σε ένα άλλο μοντέλο συναλλαγών, όλες οι τροποποιημένες σελίδες πηγαίνουν μόνο στο ΣΥΝΟΛΟ ΕΠΙΓΡΑΨΗΣ (δηλαδή, είναι ουσιαστικά καθαρό ημερολόγιο). Αυτό το μοντέλο είναι για όσους παραπονέθηκαν για τον γρήγορο κατακερματισμό των κατατμήσεων Reiser4. Τώρα σε αυτό το μοντέλο το διαμέρισμα σας δεν θα κατακερματίζεται γρηγορότερα από το ReiserFS (v3). Και τα τρία υπάρχοντα μοντέλα, με ορισμένες επιφυλάξεις, εγγυώνται την ατομικότητα των λειτουργιών, αλλά μοντέλα με απώλεια ατομικότητας και διατηρώντας μόνο την ακεραιότητα του τμήματος μπορούν επίσης να είναι χρήσιμα. Τέτοια μοντέλα μπορούν να είναι χρήσιμα για κάθε είδους εφαρμογές (βάσεις δεδομένων κ.λπ.), οι οποίες έχουν ήδη αναλάβει ορισμένες από αυτές τις λειτουργίες. Είναι πολύ εύκολο να προσθέσω αυτά τα μοντέλα στο Reiser4, αλλά δεν το έκανα, γιατί κανείς δεν με ρώτησε και εγώ προσωπικά δεν το χρειάζομαι.
Εμφανίστηκαν αθροίσματα ελέγχου μεταδεδομένων και πρόσφατα τα συμπλήρωσα με «οικονομικούς» καθρέφτες» (ακόμη ασταθές υλικό). Εάν το άθροισμα ελέγχου οποιουδήποτε μπλοκ αποτύχει, το Reiser4 διαβάζει αμέσως το αντίστοιχο μπλοκ από τη συσκευή αντιγραφής. Σημειώστε ότι τα ZFS και Btrfs δεν μπορούν να το κάνουν αυτό: η σχεδίαση δεν το επιτρέπει. Εκεί πρέπει να εκτελέσετε μια ειδική διαδικασία σάρωσης φόντου που ονομάζεται "σκράμπ" και να περιμένετε να φτάσει στο προβληματικό μπλοκ. Οι προγραμματιστές ονομάζουν μεταφορικά τέτοια γεγονότα «δεκανίκια».
Και τέλος, εμφανίστηκαν ετερογενείς λογικοί τόμοι, προσφέροντας ό,τι ZFS, Btrfs, στρώμα μπλοκ, καθώς και συνδυασμοί FS+LVM κατ' αρχήν δεν μπορούν να παρέχουν - παράλληλη κλιμάκωση, κατανεμητής διευθύνσεων δίσκου O(1), διαφανής μετεγκατάσταση δεδομένων μεταξύ υποτόμων. Το τελευταίο διαθέτει και διεπαφή χρήστη. Τώρα μπορείτε εύκολα να μετακινήσετε τα πιο δημοφιλή δεδομένα στη μονάδα δίσκου υψηλότερης απόδοσης στον τόμο σας.
Επιπλέον, είναι δυνατό να ξεπλυθούν επειγόντως τυχόν βρώμικες σελίδες σε μια τέτοια μονάδα δίσκου, επιταχύνοντας έτσι σημαντικά τις εφαρμογές που συχνά καλούν fsync(2). Σημειώνω ότι η λειτουργικότητα του επιπέδου μπλοκ, που ονομάζεται bcache, δεν παρέχει καθόλου τέτοια ελευθερία δράσης. Οι νέοι λογικοί τόμοι βασίζονται στους αλγόριθμους μου (υπάρχουν αντίστοιχες πατέντες). Το λογισμικό είναι ήδη αρκετά σταθερό, είναι πολύ πιθανό να το δοκιμάσετε, να μετρήσετε την απόδοση κ.λπ. Η μόνη ταλαιπωρία είναι ότι προς το παρόν πρέπει να ενημερώσετε με μη αυτόματο τρόπο τη διαμόρφωση της έντασης και να την αποθηκεύσετε κάπου.
Μέχρι στιγμής μπόρεσα να υλοποιήσω τις ιδέες μου κατά 10 τοις εκατό, ωστόσο, πέτυχα αυτό που θεωρούσα το πιο δύσκολο πράγμα - τη σύνδεση λογικών τόμων με μια διαδικασία flash που εκτελεί όλες τις αναβαλλόμενες ενέργειες στο reiser4. Όλα αυτά βρίσκονται ακόμα στον πειραματικό κλάδο "format41".
Το Reiser4 περνάει xfstests;
Τουλάχιστον αυτό μου έκανε όταν ετοίμαζα την τελευταία κυκλοφορία.
Είναι καταρχήν δυνατό να γίνει το Reiser4 ένα δίκτυο (cluster) FS χρησιμοποιώντας πρόσθετα;
Είναι δυνατό, και μάλιστα απαραίτητο! Εάν δημιουργήσετε ένα αρχείο δικτύου βασισμένο σε ένα σωστά σχεδιασμένο τοπικό σύστημα αρχείων, το αποτέλεσμα θα είναι πολύ εντυπωσιακό! Στα σύγχρονα δικτυακά FS, δεν είμαι ικανοποιημένος με την παρουσία ενός επιπέδου αποθήκευσης backend, το οποίο υλοποιείται χρησιμοποιώντας οποιοδήποτε τοπικό FS. Η ύπαρξη αυτού του επιπέδου είναι εντελώς αδικαιολόγητη. Το δίκτυο FS πρέπει να αλληλεπιδρά απευθείας με το επίπεδο μπλοκ και να μην ζητά από το τοπικό FS να δημιουργήσει άλλα αρχεία υπηρεσίας!
Γενικά, η διαίρεση των συστημάτων αρχείων σε τοπικά και δικτυακά είναι από το κακό. Προέκυψε από την ατέλεια των αλγορίθμων που χρησιμοποιήθηκαν πριν από τριάντα χρόνια και στη θέση τους δεν έχει προταθεί τίποτα ακόμα. Αυτός είναι και ο λόγος για την εμφάνιση μιας μάζας περιττών στοιχείων λογισμικού (διάφορες υπηρεσίες κ.λπ.). Με την καλή έννοια, θα πρέπει να υπάρχει μόνο ένα FS με τη μορφή μιας μονάδας πυρήνα και ένα σύνολο βοηθητικών προγραμμάτων χρήστη εγκατεστημένα σε κάθε μηχανή - ένας κόμβος συμπλέγματος. Αυτό το FS είναι τόσο τοπικό όσο και δικτυακό. Και τίποτα παραπάνω!
Εάν τίποτα δεν λειτουργεί με το Reiser4 στο Linux, θα ήθελα να προσφέρω ένα FS για το FreeBSD (απόσπασμα από προηγούμενη συνέντευξη: «...Το FreeBSD... έχει ακαδημαϊκές ρίζες... Και αυτό σημαίνει ότι με μεγάλο βαθμό πιθανότητας θα βρει μια κοινή γλώσσα με τους προγραμματιστές») ;
Έτσι, όπως μόλις ανακαλύψαμε, όλα έχουν ήδη λειτουργήσει τέλεια με το Linux: υπάρχει μια ξεχωριστή θύρα Reiser4 που λειτουργεί για αυτό με τη μορφή ενός κύριου κλάδου του αποθετηρίου μας. Δεν ξέχασα το FreeBSD! Προσφορά! Είμαι έτοιμος να συνεργαστώ στενά με όσους γνωρίζουν καλά το εσωτερικό του FreeBSD. Παρεμπιπτόντως: αυτό που μου αρέσει πολύ στην κοινότητά τους είναι ότι εκεί οι αποφάσεις λαμβάνονται από ένα ενημερωμένο συμβούλιο ανεξάρτητων εμπειρογνωμόνων, το οποίο δεν έχει καμία σχέση με την κυβερνητική εξαπάτηση ενός μόνιμου ατόμου.
Πώς αξιολογείτε την κοινότητα χρηστών Linux σήμερα; Έχει γίνει πιο «ποπ»;
Δεδομένης της φύσης της δουλειάς μου, είναι αρκετά δύσκολο για μένα να το αξιολογήσω. Κυρίως χρήστες έρχονται σε εμένα με αναφορές σφαλμάτων και αιτήματα για τη διόρθωση της ενότητας. Χρήστες ως χρήστες. Άλλοι είναι πιο έξυπνοι, άλλοι λιγότερο. Όλοι αντιμετωπίζονται το ίδιο. Λοιπόν, αν ο χρήστης αγνοήσει τις οδηγίες μου, τότε με συγχωρείτε: η σειρά παράβλεψης θα εισαχθεί και από μέρους μου.
Είναι δυνατόν να προβλεφθεί η ανάπτυξη συστημάτων αρχείων για τα επόμενα πέντε έως δέκα χρόνια; Ποιες πιστεύετε ότι είναι οι κύριες προκλήσεις που μπορεί να αντιμετωπίσουν οι προγραμματιστές FS;
Ναι, δεν είναι δύσκολο να κάνεις μια τέτοια πρόβλεψη. Δεν έχει αναπτυχθεί συστήματα αρχείων στο upstream εδώ και πολύ καιρό. Μόνο η εμφάνιση τέτοιων δημιουργείται. Οι προγραμματιστές τοπικών συστημάτων αρχείων αντιμετώπισαν προβλήματα που σχετίζονται με κακή σχεδίαση. Εδώ πρέπει να γίνει μια προειδοποίηση. Δεν θεωρώ ότι η λεγόμενη «αποθήκευση», «γλείψιμο» και η μεταφορά κώδικα είναι ανάπτυξη και ανάπτυξη. Και δεν κατατάσσω την παρεξήγηση που ονομάζεται "Btrfs" ως εξέλιξη για τους λόγους που έχω ήδη εξηγήσει.
Κάθε patch επιδεινώνει τα προβλήματά του. Καλά. και υπάρχουν πάντα διάφορα είδη «ευαγγελιστών» για τους οποίους «όλα λειτουργούν». Βασικά, πρόκειται για μαθητές και φοιτητές που παραλείπουν διαλέξεις. Φανταστείτε: λειτουργεί για αυτόν, αλλά ο καθηγητής όχι. Τι έκρηξη αδρεναλίνης είναι αυτή! Από την άποψή μου, το μεγαλύτερο κακό προκαλούν οι «τεχνίτες» που έσπευσαν να «βιδώσουν» με ενθουσιασμό τα υπέροχα χαρακτηριστικά του Btrfs σε όλα τα είδη των στρωμάτων όπως το systemd, το docker κ.λπ. - αυτό μοιάζει ήδη με μεταστάσεις.
Ας προσπαθήσουμε τώρα να κάνουμε μια πρόβλεψη για πέντε έως δέκα χρόνια. Έχω ήδη παραθέσει εν συντομία τι θα κάνουμε στο Reiser4. Η κύρια πρόκληση για τους τοπικούς προγραμματιστές FS από το upstream θα είναι (ναι, έχει ήδη γίνει) η αδυναμία να κάνουν μια αξιοπρεπή δουλειά έναντι ενός μισθού. Χωρίς καμία ιδέα στον τομέα της αποθήκευσης δεδομένων, θα συνεχίσουν να προσπαθούν να επιδιορθώσουν αυτά τα ατυχή VFS, XFS και ext4. Η κατάσταση με το VFS μοιάζει ιδιαίτερα κωμική σε αυτό το πλαίσιο, θυμίζοντας τον φρενήρη εκσυγχρονισμό ενός εστιατορίου στο οποίο δεν υπάρχουν σεφ και δεν αναμένονται σεφ.
Τώρα ο κώδικας VFS, χωρίς όρους, κλειδώνει πολλές σελίδες μνήμης ταυτόχρονα και καλεί το υποκείμενο FS να τις χειριστεί. Αυτό εισήχθη για να βελτιώσει την απόδοση του Ext4 στις λειτουργίες διαγραφής, αλλά όπως είναι εύκολο να γίνει κατανοητό, τέτοιου είδους ταυτόχρονο κλείδωμα είναι εντελώς ασύμβατο με προηγμένα μοντέλα συναλλαγών. Δηλαδή, δεν θα μπορείτε απλώς να προσθέσετε υποστήριξη για κάποιο έξυπνο σύστημα αρχείων στον πυρήνα. Δεν ξέρω ποια είναι η κατάσταση σε άλλους τομείς του Linux, αλλά όσον αφορά τα συστήματα αρχείων, οποιαδήποτε εξέλιξη εδώ είναι απίθανο να είναι συμβατή με την πολιτική που ακολουθεί ο Torvalds στην πράξη (τα ακαδημαϊκά έργα εκδιώκονται και οι απατεώνες δεν έχω ιδέα τι Β-δέντρο, εκδίδονται ατελείωτες πιστώσεις εμπιστοσύνης). Ως εκ τούτου, ορίστηκε μια πορεία για αργή αποσύνθεση. Φυσικά, θα προσπαθήσουν με όλες τους τις δυνάμεις να το περάσουν ως «ανάπτυξη».
Επιπλέον, οι «θεματοφύλακες» των συστημάτων αρχείων, συνειδητοποιώντας ότι δεν θα κερδίσετε πολλά μόνο από την «αποθήκευση», θα δοκιμάσουν τις δυνάμεις τους σε μια πιο κερδοφόρα επιχείρηση. Αυτά είναι, κατά κανόνα, κατανεμημένα συστήματα αρχείων και εικονικοποίηση. Ίσως μεταφέρουν το μοντέρνο ZFS κάπου αλλού όπου δεν υπάρχει ακόμα. Αλλά, όπως όλα τα FS από το ανάντη, μοιάζει με δέντρο της Πρωτοχρονιάς: αν μπορείτε να κρεμάσετε μερικά άλλα μικρά πράγματα από πάνω, τότε δεν μπορείτε να πάτε πιο βαθιά. Παραδέχομαι ότι είναι δυνατό να οικοδομήσουμε ένα σοβαρό επιχειρηματικό σύστημα με βάση το ZFS, αλλά επειδή τώρα συζητάμε για το μέλλον, μπορώ μόνο να δηλώσω δυστυχώς ότι η ZFS είναι απελπιστική από αυτή την άποψη: με τις εικονικές συσκευές τους, οι τύποι έχουν κόψει το οξυγόνο για τους ίδιους και τις μελλοντικές γενιές για περαιτέρω ανάπτυξη. Το ZFS ανήκει στο παρελθόν. Και τα ext4 και XFS δεν είναι καν προχθές.
Αξίζει να αναφερθεί ξεχωριστά η εντυπωσιακή ιδέα του «σύστημα αρχείων Linux επόμενης γενιάς». Αυτό είναι ένα εντελώς πολιτικό και μάρκετινγκ έργο που δημιουργήθηκε για την ευκαιρία, θα λέγαμε, να «καρφιτσωθεί το μέλλον των συστημάτων αρχείων» στο Linux πίσω από συγκεκριμένους χαρακτήρες. Το γεγονός είναι ότι το Linux κάποτε ήταν «μόνο για διασκέδαση». Αλλά τώρα είναι πρωτίστως μια μηχανή που βγάζει χρήματα. Κατασκευάζονται με ό,τι είναι δυνατό. Για παράδειγμα, είναι πολύ δύσκολο να δημιουργηθεί ένα καλό προϊόν λογισμικού, αλλά οι έξυπνοι «προγραμματιστές» έχουν εδώ και καιρό συνειδητοποιήσει ότι δεν υπάρχει λόγος να πιέζονται καθόλου: μπορείτε να πουλήσετε με επιτυχία ανύπαρκτο λογισμικό που ανακοινώθηκε και προωθήθηκε σε κάθε είδους κοινό συμβάντα - το κύριο πράγμα είναι ότι οι διαφάνειες παρουσίασης πρέπει να περιέχουν περισσότερες «χαρακτηριστικές».
Τα συστήματα αρχείων είναι τέλεια για αυτό, γιατί μπορείτε να διαπραγματευτείτε με ασφάλεια για δέκα χρόνια για το αποτέλεσμα. Λοιπόν, αν κάποιος αργότερα παραπονεθεί για την έλλειψη αυτού του αποτελέσματος, τότε απλά δεν καταλαβαίνει τίποτα για τα συστήματα αρχείων! Αυτό θυμίζει χρηματοοικονομική πυραμίδα: στην κορυφή βρίσκονται οι τυχοδιώκτες που ξεκίνησαν αυτό το χάος, και εκείνοι οι λίγοι που ήταν «τυχεροί»: «έβγαλαν μερίσματα», δηλ. έλαβε χρήματα για ανάπτυξη, πήρε μια καλά αμειβόμενη δουλειά ως μάνατζερ, «εμφανίστηκε» σε συνέδρια κ.λπ.
Στη συνέχεια έρχονται αυτοί που είναι «άτυχοι»: θα μετρήσουν απώλειες, θα αντιμετωπίσουν τις συνέπειες της εγκατάστασης ενός άχρηστου προϊόντος λογισμικού στην παραγωγή, «κ.λπ. Υπάρχουν πολλά περισσότερα από αυτά. Λοιπόν, στη βάση της πυραμίδας υπάρχει μια τεράστια μάζα προγραμματιστών που «πριονίζουν» άχρηστο κώδικα. Είναι οι μεγαλύτεροι χαμένοι, γιατί ο χαμένος χρόνος δεν επιστρέφεται. Τέτοιες πυραμίδες είναι εξαιρετικά ωφέλιμες για τον Torvalds και τους συνεργάτες του. Και όσο περισσότερες από αυτές τις πυραμίδες, τόσο το καλύτερο για αυτούς. Για να τροφοδοτήσετε τέτοιες πυραμίδες, όλα μπορούν να ληφθούν στον πυρήνα. Φυσικά, δημόσια λένε το αντίθετο. Δεν κρίνω όμως με λόγια αλλά με πράξεις.
Έτσι, «το μέλλον των συστημάτων αρχείων στο Linux» είναι ένα ακόμη εξαιρετικά προωθημένο, αλλά ελάχιστα χρησιμοποιήσιμο λογισμικό. Μετά το Btrfs, με μεγάλη πιθανότητα, τη θέση ενός τέτοιου «μέλλοντος» θα πάρει το Bcachefs, το οποίο είναι άλλη μια προσπάθεια να διασταυρωθεί το επίπεδο μπλοκ Linux με ένα σύστημα αρχείων (ένα κακό παράδειγμα είναι μεταδοτικό). Και το χαρακτηριστικό: υπάρχουν τα ίδια προβλήματα όπως στο Btrfs. Το υποψιαζόμουν αυτό για πολύ καιρό, και μετά με κάποιο τρόπο δεν μπόρεσα να αντισταθώ και κοίταξα τον κώδικα - είναι αλήθεια!
Οι συγγραφείς των Bcachefs και Btrfs, όταν δημιουργούσαν το FS τους, χρησιμοποίησαν ενεργά τις πηγές άλλων ανθρώπων, καταλαβαίνοντας ελάχιστα για αυτές. Η κατάσταση θυμίζει πολύ το παιδικό παιχνίδι «σπασμένο τηλέφωνο». Και μπορώ περίπου να φανταστώ πώς αυτός ο κώδικας θα συμπεριληφθεί στον πυρήνα. Στην πραγματικότητα, κανείς δεν θα δει τις «τσούγκρες» (όλοι θα τις πατήσουν αργότερα). Μετά από πολυάριθμες κουβέντες σχετικά με το στυλ του κώδικα, κατηγορίες για ανύπαρκτες παραβιάσεις κ.λπ., θα βγει ένα συμπέρασμα για την «πιστότητα» του συγγραφέα, πόσο καλά «αλληλεπιδρά» με άλλους προγραμματιστές και πόσο επιτυχώς μπορούν όλα αυτά στη συνέχεια να πωληθούν σε εταιρείες.
Το τελικό αποτέλεσμα δεν θα ενδιαφέρει κανέναν. Πριν από είκοσι χρόνια, ίσως, θα με ενδιέφερε, αλλά τώρα τα ερωτήματα τίθενται διαφορετικά: θα μπορέσει να προωθηθεί έτσι ώστε ορισμένα άτομα να απασχοληθούν μέσα στα επόμενα δέκα χρόνια. Και, δυστυχώς, δεν συνηθίζεται να αναρωτιόμαστε για το τελικό αποτέλεσμα.
Σε γενικές γραμμές, θα συνιστούσα ανεπιφύλακτα να μην αρχίσετε να ανακαλύπτετε ξανά το σύστημα αρχείων σας από την αρχή. Γιατί ακόμη και σημαντικές οικονομικές επενδύσεις δεν θα είναι αρκετές για να αποκτήσετε κάτι ανταγωνιστικό σε δέκα χρόνια. Φυσικά, μιλάω για σοβαρά έργα, και όχι για εκείνα που προορίζονται να «σπρώξουν» στον πυρήνα. Έτσι, ένας πιο αποτελεσματικός τρόπος έκφρασης είναι να συμμετέχετε σε πραγματικές εξελίξεις, όπως εμείς. Αυτό, φυσικά, δεν είναι εύκολο να γίνει - αλλά αυτό συμβαίνει με κάθε έργο υψηλού επιπέδου.
Πρώτα, θα χρειαστεί να ξεπεράσετε ανεξάρτητα το πρόβλημα που θα προσφέρω. Μετά από αυτό, πεπεισμένος για τη σοβαρότητα των προθέσεών σας, θα αρχίσω να βοηθώ. Παραδοσιακά, χρησιμοποιούμε μόνο τις δικές μας εξελίξεις. Οι εξαιρέσεις είναι οι αλγόριθμοι συμπίεσης και ορισμένες συναρτήσεις κατακερματισμού. Δεν στέλνουμε προγραμματιστές να ταξιδέψουν σε συνέδρια και μετά δεν καθόμαστε και συνδυάζουμε τις ιδέες άλλων ανθρώπων («ίσως τι θα συμβεί»), όπως συνηθίζεται στις περισσότερες νεοφυείς επιχειρήσεις.
Αναπτύσσουμε όλους τους αλγόριθμους μόνοι μας. Αυτήν τη στιγμή με ενδιαφέρουν οι αλγεβρικές και συνδυαστικές πτυχές της επιστήμης αποθήκευσης δεδομένων. Συγκεκριμένα, πεπερασμένα πεδία, ασυμπτωτικά, απόδειξη ανισοτήτων. Υπάρχει επίσης δουλειά για απλούς προγραμματιστές, αλλά πρέπει να σας προειδοποιήσω αμέσως: αγνοούνται όλες οι προτάσεις για να "κοιτάξετε ένα άλλο FS και να κάνετε το ίδιο". Οι ενημερώσεις κώδικα που στοχεύουν στη στενότερη ενσωμάτωση με το Linux μέσω VFS θα πηγαίνουν επίσης εκεί.
Άρα, δεν έχουμε τσουγκράνα, αλλά καταλαβαίνουμε πού πρέπει να κινηθούμε και έχουμε πεποίθηση ότι αυτή η κατεύθυνση είναι η σωστή. Αυτή η κατανόηση δεν ήρθε με τη μορφή μάννα από τον ουρανό. Να σας θυμίσω ότι έχουμε 29 χρόνια εμπειρίας ανάπτυξης πίσω μας, δύο συστήματα αρχείων γραμμένα από την αρχή. Και τον ίδιο αριθμό βοηθητικών προγραμμάτων ανάκτησης δεδομένων. Και αυτό είναι πολύ!
Πηγή: opennet.ru