Fragen? Antworten! Siehe auch: Alternativlos
Das ist wohl keine gute Idee. Lieber auf Blockdevice-Ebene RAID machen und dann normal btrfs drüber. Oder lieber gar kein btrfs und lieber ext4; da weiß man wenigstens, dass das gut abgehangen ist :-)
Und früher war das vielleicht mal ein Argument. Als man für den Einbau einer Festplatte noch SCSI-Kabel legen und eine Blutspende des Admins abgeben musste.
Selbst wenn bösartige USB-Sticks in aller Munde sind, endet die Debatte häufig bei Autoruns. Aber was wenn da jemand ein bösartiges Filesystem drauftut? Ich persönlich fand ja, dass das schon seit iSCSI und Fibre Channel und so nicht mehr wegzudiskutieren ist als Problemklasse.
Und so freut es mich sehr, dass es da jetzt einen konzertierten Anlauf gibt, die Filesysteme unter Linux mal robuster zu machen. Es geht ja nicht nur um Security. Man will ja auch nicht, dass der Kernel panict, nur weil auf einer alten Gammelplatte ein paar Bits geflippt sind.
Die Ergebnisse sind ungefähr, wie ich sie erwartet hätte. ext4 hat am längsten durchgehalten (deshalb setze ich das auch überall ein). Am schnellsten ist btrfs gestorben. XFS hielt erstaunlich lange durch, aber nicht so lange wie ext4. Naja und die ganzen Novelty-Filesysteme sterben natürlich alle recht schnell. Da sind die Autoren ja froh, wenn der Code durch-kompiliert.
Man muss dazu sagen, dass das nicht einfach nur ein Dumb Fuzzer war, sondern AFL, das ist ein adaptiver Fuzzer mit einer Art genetischem Programmieren. Der instrumentiert den Code und baut dann Testcases, um die Coverage zu maximieren, um jede Kombination aus Codepfaden mal genommen zu haben. Das Ding ist State of the Art. Wenn Code das überlebt, haben die Programmierer was richtig gemacht.
Infrastruktur wird überhaupt nur beurteilt, wenn sie versagt - ansonsten wird sie gar nicht wahrgenommen. Der Linux-Kernel wird an "ReiserFS/btrfs/XFS/ext4 hat meine Daten gefressen" und an "Der Kernel cored, wenn die Kiste aus dem Sleep aufwacht" gemessen und nicht an "Oh, der write(2) System Call hat meine Daten tatsächlich auf die Platte geschrieben.Ich stimme dem im Detail nicht zu (ich bewerte den Kernel auch nach neuen Features und Performancegewinnen bei alten Features), aber das kann man auch durch geschickte Wortauslegung wegdefinieren. Die Ausführungen finde ich trotzdem weiterhelfend und konnte das so auch schon beobachten. Bei so langen Statements erwähne ich häufig den Einsender nicht, aber in diesem Fall linke ich mal auf ein vergleichbares Statement von ihm, denn Kris macht das seit vielen, vielen Jahren und weiß, wovon er spricht. Das Verständnis der verschiedenen Herangehensweisen von Infrastruktur-Kram und Feature-Kram ist wichtig und es kann uns allen nur hilfreich sein, wenn wir es uns immer mal wieder vor Augen führen.Das ist ein großer Unterschied zu Libreoffice, das keine Infrastruktur ist und an neuen Best Cases (= neue Features) statt an seinen Worst Cases gemessen zu werden.
Infrastrukturentwickler verwenden also dieselben Sprachen, Tools, Unit-Tests, VCVSe und dergleichen mehr, arbeiten aber unter einem komplett anderen Wertesystem.
Wenn da einer auf der LKML ankommt und zeigt "Hier, neuer shiny code" (= neuer Best Case), dann wissen die schon, daß der aus einem anderen, falschen Universum ist. Infrastrukturentwickler wissen, daß Code auch immer Bugs/LoC hat, also eine Liability und kein Asset ist. Das kann man natürlich versuchen, solchen Personen immer wieder, und wieder, und wieder zu erklären, aber das kostet mehr Energie als es wert ist.
Man will in einer Infrastruktur auch nicht mehr Leute haben. Wenn wenn man da einmal genug Teilnehmer hat, daß das Projekt läuft, dann sind mehr Leute auch kein Asset, sondern eine Liability - und das gilt nicht nur für die LKML-Regulars oder Kernel-Committer, oder glibc-Developer, sondern auch für Leute, die Deine Gasleitungen oder Stromkabel warten, und sogar für Wikipedia Admins (sic!). Das ist ein ganz besonderer Menschenschlag, mit einer besonderen Arbeitsethik, die vollständig daraus stammt, daß die ihre Arbeit dann gut machen, wenn sie ihnen nicht gedankt wird und sie einfach niemand bemerkt.
Infrastrukturprojekte wollen nicht nur Deinen Code nicht, sondern auch Deine Mitarbeit nicht, weil sie - ausreichend Basis-Masse vorausgesetzt - beides nicht brauchen. Insbesondere können sie Dich nicht brauchen, wenn Du nicht diesen Infrastruktur-Mindset hast, weil Du sonst auch die Kritik und die Arbeitssituation unter einer Fail-Metrik wie sie bei Infrastuktur herrscht nicht aushältst.
Wenn man da als shiny bling bling Feature-Developer hin kommt, oder als eine 'Findet mich und meine Anliegen wichtig'-SJW-Mentalität, dann passiert eine Sarah Sharp.
Die einzige gute Nachricht an der Stelle ist, dass das anscheinend nur den IA64-Branch betrifft, und IA64 ist ja eh tot.