Diskussion:XFS (Dateisystem)

Vllt. drauf hinweisen, dass XFS "stärker" als andere Dateisystem dazu neigt, beim harten Crash Dateiinhalte zu verlieren (ich meine, das liegt an seinem sehr aggressiven Caching)? -- 217.94.168.179 03:40, 14. Mai 2005 (CEST)Beantworten

ja, xfs stellt alle Transaktionen solange wie es moeglich ist im Cache zurueck, was bei einen z.B. Stromausfall Probleme mit der Datenkonsistenz verursachen kann...

(Der vorstehende Beitrag stammt von The 194.231.230.60 – 16:48, 11. Jul. 2005 (CEST) – und wurde nachträglich signiert.)Beantworten

Aber zumindest bei SGI-Hardware besitzen die Platten wohl eine Art "USV". Daher ist das Problem erst bei Linux wichtig. Was ist eigentlich mit cXFS, also der kommerziellen Cluster-Version von XFS? Sollte man dazu nicht was schreiben? [Richard]
(Der vorstehende Beitrag stammt von 85.180.48.180 – 23:09, 24. Jul. 2005 (CEST) – und wurde nachträglich vollständig signiert.)Beantworten

"xfs stellt alle Transaktionen solange wie es moeglich ist im Cache zurueck" ist schlichtweg falsch. Es ist weitaus komplizierter. Elevators sortieren Daten um und schreiben gesammelt. Dazu gibt es Caches und Buffer und diverse Parameter das zu beeinflussen. Sie warten nicht "so lange wie möglich". Die Details korrekt darstellen: entweder als Exkurs vollständig und richtig oder es dabei belassen, dass verzögert geschrieben wird: Elevators und Transaktionssicherung. "Solange wie möglich" ist falsch. Ausserdem ist der problematischte Cache (write back cache) auf der Platte, der Hardware selbst - auch den kann man ausschalten, so es die Hardware erlaubt. Besonders problematisch wird der, wenn er von einer anderen Anordnung der Daten auf der Hardware ausgeht als das Dateisystem. Dann laufen die Optimierungen(puffern, sortieren der Daten) gegen eine erneute Umsortierung und puffern durch die Hardware selber was zu erheblichen Latenzen führen kann. Bei Raid u.U. noch stärker.

Wie gesagt Details: es wird nicht "so lange wie möglich"(was in manchen Fällen unendlich hiesse: natürlich nicht!) gewartet. Es gibt ein verzögertes schreiben, was je nach Anwendungsfall Nach- oder Vorteil sein kann. Kann also durchaus als Nachteil aufgeführt werden - ist ja auch als solcher aufgeführt.

Hat dieses Wunderdateisystem (nach diesem Artikel könnte man den Eindruck bekommen) auch größere Nachteile? -- Nameless 15:08, 30. Jul 2005 (CEST)

Ja.. Das schmeckt mir zu sehr nach einem Werbeartikel! Die schon oben genannten Nachteile, wenn XFS ohne eine USV (unterbrechungsfreie Stromversorgung) benutzt wird, sollten mehr hervorgehoben werden. --217.189.168.114 12:38, 26. Dez 2005 (CET)

Das komische bei diesem angeblichen Nachteil ist doch aber, dass dieser bei Ext4 nicht als Nachteil erklärt wird. Also irgendwie riecht mir das jetzt im Nachhinein eher nach Ausredekampagne der Ext-Programmierer, warum man blos kein XFS einsetzen sollte - es hätte ja, Gott bewahre, auch passieren können, dass sich XFS überall etabliert hätte, bevor Ext mit Ext4 wieder ein klein wenig zeitgemäß geworden ist. Jetzt ist Ext4 "feature-complete", nutzt das gleiche Allocate-On-Flush- bzw. Delayed-Allocation-Prinzip wie XFS und jetzt können wir zugeben, dass das eigentlich total geil ist. Und wenn die Ext-Programmierer dann irgendwann auch mal wieder ein mit den aktuellen Ext-Dateisystemen funktionierendes Defrag machen sollten, werden wir auch wieder zugeben dürfen, dass Fragmentierung auch auf unseren heiligen Linux-Dateisystemen ein großes Problem ist, siehe [1], bei dessen Linderung Delayed Allocation sehr hilfreich ist. Irgendwann könnte übrigens mal jemand diese Diskussionspunkte hier oben auch unter eine Teilüberschrift setzen, so dass diese Punkte auch unter und nicht über dem Inhaltsverzeichnis stehen. ;-) --SvenEric 18:57, 12. Dez. 2008 (CET)Beantworten

Die Kommentare haben irgendwie den Geruch eines Kleinkrieges XFS gegen EXT: was soll das? Macht vielleicht bei einem Vergleich Sinn. Klar Ext4 hat auch Vor- und Nachteile. Die interessieren hier aber nicht, weil der Artikel nicht Dateisysteme vergleicht sondern eines vorstellt: XFS. Momentan ist es tatsächlich so,

a) XFS unterstützt Dateisystemverkleinerung in den üblichen Auslieferungen nicht. Es gibt xfs_growfs aber kein xfs_resizefs(o.ä.). https://xfs.org/index.php/Shrinking_Support

b) XFS kennt selber kein undelete. https://xfs.org/index.php/XFS_FAQ#Q:_Does_the_filesystem_have_an_undelete_capability.3F - Es gibt Projekte die sich dem widmen aber XFS nicht.

c) "Verzögerte Belegung". Das ist so,wie beschrieben unklar. Es ist ein Journaling Filesystem d.h. auf Konsistenz durch Rollback bei Störung ausgelegt aber verhindert nicht Datenverlust. Verweis zu Journaling Dateisystemen https://de.wikipedia.org/wiki/Journaling-Dateisystem ist gegeben. Eindeutig bereits eine Design Eigenschaft des Filesystems, den man als Nachteil aufführen kann. (Ohne weiter in Details zu gehen müssen: Als Journaling Filesystem ist es mit dieser Eigenschaft behaftet, dass inkonsistente Daten verworfen werden bis zur vollständigen konsistenten Transaktion von gepufferten - verzögert - Daten. )

d) Zur Fragmentierung: ein Kampfbegriff. Einen Nachteil stärkerer Fragmentierung ist XFS kaum nachzusagen. Es hat keine verketteten Dateizeiger, an denen es sich entlang hangeln muss. Es muss nicht alle Teile einer ganze Datei durchsuchen(und zusammensuchen) um das Ende zu finden oder eine bestimmte Stelle innerhalb der Datei. In diesem Sinne, kann es nicht fragmentieren. Daneben gibt es aber auch zusätzliche andere Fragmentierung. Bei allen Dateisystemen. XFS ist durch Extents besonders stark in deren Vermeidung. Mit xfs_fsr existiert ein Tool, um Defragmentierung durchzuführen. Einen faktischen Nachteil könnte man bzgl. Hardwarefragmentierung finden besonders bei SSD: discard/trim ist nötig zur Hardwaredefragmentierung.[der Unkenschreie bzgl Bias wegen: ich persönlich präferiere EXT gegenüber XFS. Ich habe über viele Jahre bessere Erfahrungen mit Ext und schlechtere mit XFS gemacht fahre aber auch größere Systeme mit XFS. Aber die praktische Relevanz von Schreibverzögerung oder Fragmentierung rechtfertigt eigentlich nicht diese große Diskussion. Wo das ein Problem darstellt, muss man sehr viel tiefer einsteigen. Vielleicht auch mal einen Realitätscheck machen: Ein spezial System ohne USV also unter Inkaufnahme einer Downtime, dass auf Transaktionssicherung verzichtet aber dann ohne Zusatzmaßnahmen wie Cluster, Sharding, Splits, Datenredundanz, Snapshots usw. usf. sofort/direkt auf Persistenzlayer Platte geht und keinen Datenverlust haben soll?].

Ich habe den Artikel versucht aussagekräftiger zu machen, indem ich weite Teile des englischsprachigen Artikels ins Deutsche übersetzt habe. Ich hoffe, die Objektivität ist dadurch besser gewährleistet, wenngleich sicherlich immer noch einige Aspekte nicht ausreichend betrachtet wurden. :-) Mathias 20:56, 24. Mai 2006 (CEST)Beantworten

Naja, ich sehe da ein kleines Problem, an folgender Stelle:

GRIO = Guaranteed IO Bandwidth (Garantierte E/A Bandbreite), speziell für z. B. Streaming (Video) Server

Soll der Artikel für 'Normalsterbliche' lesbar sein, muss man E/A auch Ausschreiben, sollen nur Leute die sich mit der Materie auskennen das verstehen können, reicht das englische. Ich wäre also für eine Ausschreibung von Eingabe/Ausgabe (sollte doch richtig sein, oder?) --Hco 15:02, 24. Sep 2006 (CEST)

Der Teil mit den variablen Blockgrößen stimmt so nicnt, zumindest wenn man der englischen Version glauben darf. XFS unterstützt zwar unterschiedliche Blöckgrößen, die sind aber nach Erstellen des Dateisystems nicht mehr zu ändern (d.h. nicht variable). Alles andere wäre auch ziemlich überraschend gewesen.
(Der vorstehende Beitrag stammt von 84.58.230.45 – 00:14, 9. Jul. 2006 (CEST) – und wurde nachträglich signiert.)Beantworten

Müsste es hier "XFS ist durch das verzögerte Schreiben von Daten möglicherweise anfälliger für Crashs (z.B. bei Stromausfällen)." nicht "Datenverlust" heißen, statt "Crashs"? Hört sich für mich logischer an, habe aber keine Ahnung von XFS. :-)
(Der vorstehende Beitrag stammt von Admiral kay – 09:54, 16. Sep. 2006 (CEST) – und wurde nachträglich signiert.)Beantworten

Bevor die Diskussion überhaupt beginnt: XFS will auf eine Fragmentierung der Daten verzichten. Eine Defragmentierung ist dann erst gar nicht notwendig. Es ist nicht richtig zu behaupten, XFS würde auf eine Defragmentierung verzichten. Richtig ist: Diese wird erst durch XFS verzichtbar. Daher der revert. -- Mathias bla? 20:21, 24. Okt. 2006 (CEST)Beantworten

Verzichtbar wird sie nicht ganz, XFS ist zwar weniger 'anfällig' für Fragmentation, trotzdem ist sie vorhanden. Wozu sonst sollte es zB. xfs_fsr geben? --85.176.225.161 00:56, 1. Apr. 2008 (CEST)Beantworten

Korrekt! (nicht signierter Beitrag von 92.217.12.187 (Diskussion) 19:45, 17. Jul. 2022 (CEST))Beantworten

Ich finde, man sollte xfs_repair nicht auf einen anderen Artikel verlinken. Dafuer ist es meines Erachtens nach zu unwichtig. Sollte es denn aber nicht vlt. unter Hilfsmittel aufgefuehrt werden? Ist nicht meine Thematik, aber ich wollte mal meinen Senf zugeben ;) --Hco 08:19, 15. Dez. 2006 (CET)Beantworten

Ich habe das mal abgeändert. Hilfsmittel, für ein (zugegeben wichtiges) Dateisystem sollten nur im Artikel über Dateisysteme erscheinen (Relevanz wäre sicherlich nicht gegeben, daher verleitet der rote Link dazu, einen Artikel zu schreiben, der sofort gelöscht würde). -- Mathias bla? 10:55, 15. Dez. 2006 (CET)Beantworten

"Gelöschte Dateien sind nicht wiederherstellbar." Warum ist das als Nachteil gelistet? Es koennte auch genau so gut einen Vorteil darstellen. Dazu einmal die Frage wer denn jemals eine "geloeschte Datei wieder herstell funktion" vermisst hat. Und im Verhaeltnis dazu Diejenigen, die gern ihre geloeschten Daten auch gern geloescht wuessten. Ich persoenlich hatte nie das Beduerfnis, etwas Geloeschtes zu rekonstruieren und wirklich jedes Mal, wenn ich etwas lösche(etwa zehnmal pro Tag) den Wunsch, dass es auch wirklich weg ist. (nicht signierter Beitrag von 86.103.226.102 (Diskussion | Beiträge) 01:56, 4. Jun. 2009 (CEST)) Beantworten

Lächerlicher Dummfug, natürlich ist das ein Nachteil, ein ernstzunehmender sogar. Wenn man bestimmte sensible Dateien unwiederruflich löschen möchte, die dann auch wirklich dauerhaft entfernt sein sollen, so gibt es entsprechende Tools und Verfahren hierzu. --Benatrevqre ^…?! 14:45, 7. Mär. 2010 (CET)Beantworten

Lächerlich ist der Streit. Wenn man wirklich sensible Dateien hat, will man vielleicht auch sicher stellen, dass nach Löschung keine Hintertür besteht, Zugang zu diesen Daten zu erhalten: irrelevant.

Wiederherstellen gelöschter Dateien ist nur über zusätzliche Tools möglich. Diese Fähigkeit besitzt XFS nicht. Es sollte erwähnt sein und dem Leser überlassen, ob es für ihn einen Nachteil darstellt. (Vielleicht isollte man die Einteilung "Nachteil/Vorteil" durch "Eigenschaften" ersetzen.) (nicht signierter Beitrag von 92.217.12.187 (Diskussion) 20:18, 17. Jul. 2022 (CEST))Beantworten

Ja, derzeit ist das so, aber XFS wird intensiv weiterentwickelt und es ist mittlerweile eine Snapshotfunktion (und eine Selbstheilungsfunktion) geplant, wodurch einiges neu zu bewerten sein wird. --Liebeskind (Diskussion) 22:08, 22. Okt. 2024 (CEST)Beantworten

Wie im Artikel Byte dargelegt, gibt es passendere Begriffe als die bislang gebräuchlichen. Ich habe deshalb die Werte in der Infobox geändert.

FIXME: Dadurch unterscheiden sich jetzt die Werte/Bezeichnungen in der Infobox und im Text. --Thommy 22:23, 2. Feb. 2007 (CET)Beantworten

8 Exbibyte sind nicht mehr als 9 _Millionen_ Exabyte sondern mehr als 9 Exabyte. Zur besseren Vorstellung habe ich 9 Millionen Terabyte gewählt. -- 85.183.154.164 16:57, 25. Feb. 2008 (CET)Beantworten

Ja. Nur wird bei Storage allgemein und seit je her mit SI also 1K=1000 gerechnet und nicht mit 1024. Storage Größen sollten daher Konventionsgemäß in Exabyte angegeben sein und nicht in Exbibyte. Das heisst, die Umbenennung ist falsch bzw irreführend. Exabyte sind Exabyte und eben nicht Exbibyte(wie erwähnter Artikel richtig beschreibt). Also: nicht durcheinander werfen und nicht mit Exbibyte benennen, was Exabyte ist.

Laut englischem Artikel gibt es keine Begrenzung der Länge der Pfadnamen im Dateisystem an sich. Sehr wohl besteht jedoch eine Begrenzung dieser in den verschiedenen Implementierungen(z.B.: Linux-Kernel). Dies sollte an der Stelle an der auf die 255 Zeichen im Dateinamen hingewiesen wird, erwähnt werden. Siehe:

• http://en.wikipedia.org/wiki/Comparison_of_file_systems#_ref-note-25_0
• http://en.wikipedia.org/wiki/Comparison_of_file_systems#_note-note-12

(Der vorstehende Beitrag stammt von 78.53.192.27 – 16:28, 27. Jan. 2008 (CET) – und wurde nachträglich signiert.)Beantworten

Datensicherung und Größenänderung im laufenden Betrieb (ohne Aushängen des Dateisystems)

In aktuellen Implementierungen ist es nicht möglich, ein XFS-Dateisystem zu verkleinern (nicht signierter Beitrag von 88.217.65.153 (Diskussion) 15:07, 28. Apr. 2008)

hmm. Richtig. Nur Vergrößerung ist möglich. Aber das geht "hot" also ohne aushängen. (nicht signierter Beitrag von 92.217.12.187 (Diskussion) 20:21, 17. Jul. 2022 (CEST))Beantworten

Unter IRIX, wofür es ursprünglich entwickelt wurde unterstützt XFS weitaus größere Blockgrößen als unter Linux, Beispielsweise 64 MiB. (nicht signierter Beitrag von 141.76.90.177 (Diskussion | Beiträge) 16:23, 16. Nov. 2009 (CET)) Beantworten

Richtig und die Konfiguration ist weit komplexer. Das wäre aber eine größere Überarbeitung - vielleicht sogar ein zweiter Artikel. Da liegen Welten dazwischen. --92.217.12.187 20:25, 17. Jul. 2022 (CEST)Beantworten

Was bedeutet „XFS“ ausgeschrieben?
--Konrad – 14:53, 24. Mär. 2010 (CET)Beantworten

Zum X kann ich nur Vermutungen anstellen. FS steht offensichtlich für "file system", also auf Deutsch Dateisystem. --Ijbond (Diskussion) 09:07, 19. Sep. 2012 (CEST)Beantworten

X steht -vermutlich- für eXtended... --84.175.235.111 11:03, 1. Nov. 2015 (CET)Beantworten

Das ist schon lange nicht mehr aktuell und sollte vielleicht mal im Artikel angepasst werden. Im damals verlinkten Bug ist sogar schon ein erster Fix zu finden, das Problem als solches gibt es schon lange nicht mehr.

--188.106.197.94 12:24, 18. Jan. 2013 (CET)Beantworten

Gerne, wenn Du einen Beleg lieferst. Gruß --Cvf-ps^Disk_+/− 13:44, 18. Jan. 2013 (CET)Beantworten

Im Artikel ist zu dem genannten Bug ein Thread der Debian Bug Mailingliste referenziert. Gemäß Debians eigenem Changelog Eintrag zur Deaktivierung von XFS auf ARM (und Schließen des als Quelle genannten Bugs) ist dies in Kernel 2.6.34 behoben. --Peter J. W. (Diskussion) 15:48, 6. Feb. 2017 (CET)Beantworten

Vielleicht sollte nicht die Kernelversion 2.4 als Beispiel eines "heutigen" Betriebssystems angeführt werden. Aktuell ist 3.13 oder sogar 3.15. (nicht signierter Beitrag von 91.66.217.152 (Diskussion) 00:52, 2. Okt. 2014 (CEST))Beantworten

wird sind mittlerweile bei 5.x ;)

Da XFS in den vergangenen Jahren eine extreme Weiterentwicklung durchgemacht hat, mitsamt Austausch den On-Disk-Formates, müsste der Artikel eigentlich in einen chronologischen Überblick umgewandelt werden, in dem die jeweilige Linux-Kernel- und die xfsprogs-Version zum jeweiligen Merkmal angegeben ist. Was bei XFS vor 3, 5 oder 10 Jahren noch gegolten hat, verhält sich nun völlig anders und ohne das chronologisch darzustellen, kenn man sich einfach nicht mehr aus. --Liebeskind (Diskussion) 19:11, 2. Dez. 2021 (CET)Beantworten

Fang an damit ;) --92.217.12.187 20:22, 17. Jul. 2022 (CEST)Beantworten

Das gilt aber nur für XFS unter Linux. XFS wurde aber auch unter anderen Betriebssystemen unterstützt... ‣Andreas•⚖ 23:57, 18. Jul. 2022 (CEST)Beantworten

Ja, wurde es, mit Betonung auf Vergangenheit. IRIX wird seit 2006 nicht mehr entwickelt (offiziell eingestellt) und FreeBSD hat XFS nur für den Import von Daten von Linux angeboten und mittlerweile gestrichen. Und das heutige XFS ist mittlerweile so stark transformiert worden, dass viele Aussagen von vor 10 oder 15 Jahren einfach keine Gültigkeit mehr haben. RedHat ist mittlerweile die führende Firma, die die Entwicklung vorantreibt und XFS als lizenztechnisch mit Linux kompatible Kobkurrenz zu ZFS aufbaut. XFS soll in naher Zukunft auch Selbstheilungsfähigkeiten und Snapshots als neue Funktionen eingebaut bekommen. Das ist einfach nicht mehr das gleiche Dateisystem. --Liebeskind (Diskussion) 13:29, 22. Okt. 2024 (CEST)Beantworten

Obwohl das natürlich stimmt, ist die Weiterentwicklung von XFS natürlich weiterhin XFS. Man kann ja auch nicht hergehen und sagen, NTFS 1.x ist nicht (mehr) dasselbe Dateisystem wie NTFS 3.x: stimmt zwar, aber auch wieder nicht. Eindeutiger ist es nur beim extended filesystem, wo ext2, ext3 und ext4 sogar eigene Artikel haben, und dennoch ist es dasselbe Dateisystem, weil überführbar (sogar in Richtung ext4 → ext2, wenn die Features stimmen). Auch, dass ein Treiber für ext2/3/4 ausreicht, ist ein gutes Indiz.

Ja, IRIX ist ein historisches Betriebssystem, wird nicht mehr weiterentwickelt, und damit natürlich die XFS-Implementierung von IRIX auch nicht mehr. Den Schluss, dass es sich bei XFS in Linux nicht mehr um dasselbe Dateisystem handeln würde, kann ich aber nicht nachvollziehen. Anders als bei ZFS, wo es zwei inkompatible Linien gibt, ist das bei XFS ja nicht so; außerdem war (anders als bei ZFS) die Offenlegung und Integration von XFS in Linux ja die Idee von SGI selbst. Inkompatibilitäten zwischen älteren und neueren Versionen eines Dateisystems sind eigentlich normal, wenn ein Dateisystem aktiv weiterentwickelt wird, so zu beobachten (gewesen) etwa auch bei ext4.^Bsp.

Zum Artikel: Ja, man könnte die ab ~2010 hinzugekommenen Features genauer herausarbeiten/vorstellen. Beispiele:

• XFS in der Arch Wiki
• heise online, 2014: Linux-Dateisystem XFS soll verlässlicher arbeiten
• heise online, 2016: Linux 4.8: Vorboten neuer XFS-Funktionen und Schnellstraße im Netzwerk-Stack
• Linux Magazin, 2022: Kernel 5.19: XFS rüstet auf, höfliches NFS und Apple-News

‣Andreas•⚖ 15:09, 22. Okt. 2024 (CEST)Beantworten

Nachtrag: Worauf ich hinaus wollte: IRIX XFS und Linux XFS, natürlich sind beide XFS, aber eben in unterschiedlichen Versionen, so wie Windows NT 3.1 NTFS nutzt, aber eben in einer anderen Version als Windows 11. Und auch bei ext4 ist das so, dass ältere Distributionen eine ältere ext4-Version nutzt (weniger Features) als eine aktuelle. Aber hier ist es immer dasselbe Betriebssystem, und ich wollte darauf hinaus, dass das bei XFS nicht so ist: IRIX ist nicht Linux. Andere Beispiele von Dateisystemen, die von mehreren Betriebssystemen genutzt wurden/werden, sind u.a. ZFS, JFS oder HPFS.

Bei FAT32 und exFAT ist es ja eher so, dass diese eine fertige Spezifikation darstellen. Weiterentwicklungen werden hier entweder bewusst vermieden oder per neuerer Spezifikation abermals standardisiert, obwohl das bei FAT eher ein Unfall (Zufall) war, nicht aber bei exFAT. Dass FAT also Betriebssystem-übergreifend funktioniert, ist heute kein Zufall mehr...

Was ich mir dabei gedacht habe? Für den Artikel würde das bedeuten, dass man XFS schon so vorstellen kann, dass es den Zustand mit IRIX und Linux 2.6 historisch beschreibt. Die Neuerungen ab ~2010 würde ich zwar hinzufügen, aber eben in den Kontext von Linux stellen. Das war es, worauf ich hinaus wollte. Ich entschuldige mich dafür, dass das nicht rüber kam...

‣Andreas•⚖ 15:23, 22. Okt. 2024 (CEST)Beantworten

Habe nun im Abschnitt Geschichte von XFS verdeutlicht, dass von XFS v4 auf XFS v5 (Linux 5.10) ein harter Bruch gemacht wurde, da ein Upgrade nur durch eine Neuformatierung möglich ist und die Unterstützung von XFS v4 im Linux-Kernel nur bis 2025 garantiert ist. (Da bist XFS v4 das Jahr-2038-Problem besteht, sollte ohnehin ehebaldigst neu formatiert werden.) --Liebeskind (Diskussion) 08:22, 31. Okt. 2024 (CET)Beantworten

Danke! Interessant finde ich, dass in der Infobox auch FreeBSD angeführt wird, aber wenn ich danach suche, finde ich nur Read-Only support ab FreeBSD 7.0 (2008)^ref und dass es mit FreeBSD 10 (2013) still und leise wieder verschwand.^ref Allerdings gibt es widersprüchliche Angaben zu den genauen Zeiträumen (bzw. damit auch den FreeBSD-Versionen) dazu.^{ref, ref} Auch das sollte man nach weiterer Recherche vielleicht anpassen. ‣Andreas•⚖ 20:09, 31. Okt. 2024 (CET)Beantworten

(1) Ja, die Unterstützung durch FreeBSD ist offensichtlich eine historische und das doppelt, da vermutlich auch ein historisches FreeBSD kein XFS v5 lesen kann. (2) Ich habe jetzt deine obige Argumentation noch einmal im Lichte der Erkenntnis, dass XFS v4 nicht zu XFS v5 konvertiert werden kann, gelesen. Die Fehlende Überführbarkeit spricht fast dafür, dass es sich um zwei verschiedene Dateisysteme handelt, wobei XFS v5 natürlich eindeutig eine Weiterentwicklung von XFS v4 ist. --Liebeskind (Diskussion) 23:04, 1. Nov. 2024 (CET)Beantworten

Naja... Zwei verschiedene Dateisysteme? XFS v4 in Linux hat auch vor dem harten Bruch einige Features eingeführt, die in früheren v4-Impementierungen fehlen, und ob XFS v4 von Linux wirklich mit XFS von FreeBSD bzw. XFS in IRIX kompatibel ist, lässt sich ohne Quelle und ohne Tests nicht einfach feststellen.

Ich halte es daher für WP:TF, zu sagen: "XFS v4 und XFS v5 sind zwei verschiedene Dateisysteme". Ein anderes Beispiel: ext2 hat standardmäßig eine Inode-Größe von 128 Bits. Darin passen nicht alle Informationen, die später dazukamen, beispielsweise der um 2 Bits erweiterte Zeitstempel um das Jahr-2038-Problem zu lösen. Mit dem "extra_isize"-Feature wird die Größe der Inodes auf 256 Bits angehoben. Selbst, wenn das der einzige Unterschied ist, ist das Dateisystem damit jedoch nur noch als ext4 nutzbar. Andererseits gibt es ext4-Dateisysteme neuerer Linux-Versionen, die Features nutzen, die in älteren Linux-Versionen fehlen. Versucht man nun ein solches ext4 in einem älteren Linux einzuhängen, erhält man die Fehlermeldung "couldn't mount RDWR because of unsupported optional features".

So, was heißt das nun? Im ersten Beispiel ext2 mit extra_isize wird ext2 zu ext4, obwohl sich fast nichts ändert außer die Größe einer Struktur. Im zweiten Beispiel ist es jedoch dasselbe Dateisystem, ext4, und dennoch ist es "nicht dasselbe Dateisystem", weil es ein(einen) neueres(neueren) Betriebssystem-(Kern) benötigt?

Das wäre doch nun wirklich WP:TF... Und so wäre es auch bei XFS.

‣Andreas•⚖ 08:53, 2. Nov. 2024 (CET)Beantworten

Nachtrag: nachzulesen im Artkel extended filesystem. Ja, wir haben die extrigen Artikel ext2, ext3 und ext4. Ob wir das bei XFS auch machen sollten, und einen eigenen Artikel zu XFSv5 brauchen? Ich denke nicht, aus folgendem Grund: XFS lässt sich gut in einem einzigen Artikel abbilden. Das historische XFS kann darin genauso beschrieben werden wie das aktuelle, das es ohnehin nur noch auf Linux gibt. ‣Andreas•⚖ 08:58, 2. Nov. 2024 (CET)Beantworten

Das sehe ich auch so. Aber es sollte aus dem Artikel klar hervorgehen, dass auf alte Versionen zutreffende Aussagen für neuere keine Gültigkeit mehr haben. Etwa was die Fehleranfälligkeit nach einem hard reset betrifft. Das kann ich hier in der Diskussion aus eigener Erfahrung sagen — in den frühen Jahren war es unter Linux so, dass mein XFS regelmäßig kaputt war, wenn ich aus irgeneinem Grund den Rechner ohne Herunterfahren ausschalten musste. Ich habs dann in den letzen Jahren wieder mit XFS probiert und es ist nie mehr etwas derartiges vorgekommen. Lediglich einmal hat GParted eine Partition beim Vergrößern zerschossen. Sollte es Quellen dazu geben, wäre es gut, diese zu zitieren und in den Artikel einzubauen. Auch dazu, dass eine Vergrößerung einer mit XFS formatierten Partition zwar möglich ist, aber zu unsauberen Resultaten führt und es sicherer ist, frisch zu Formatieren. Zusätzlich wären vielleicht historische Benchmarks im Vergleich zu aktuellen wären interessant. --Liebeskind (Diskussion) 12:10, 2. Nov. 2024 (CET)Beantworten

Okay, dann habe ich dich bloß falsch verstanden. Ja, was du schreibst, sehe ich auch so. Ich nutze XFS nicht. Ich nutzte es zw. ~2000 (2001?) und ~2008, es war ein stabiles System. Ich bin dann auf ext4 umgestiegen und habe daher keine neueren Erfahrungen mit XFS. Aber darum geht es ja auch garnicht, denn das wäre eine persönliche Sichtweise, und daher WP:POV, was zwar hilft, aber nicht den Qualitätsansprüchen der WP entspricht...

Willst du das nun überarbeiten, oder sollen wir inzwischen einen entsprechenden QS-Baustein einbauen, und den Artikel als veraltetet und überarbeitungsbedürftig markieren?

‣Andreas•⚖ 12:49, 2. Nov. 2024 (CET)Beantworten

Ich glaub es geht auch ohne Baustein. Immer wieder in kleinen Schritten etwas hinzufügen und dann wird das schon. --Liebeskind (Diskussion) 20:18, 2. Nov. 2024 (CET)Beantworten

Und wenn man die historische Entwicklung beschreiben will, wäre es sinnvoll, zumindest kurz zu erklären, dass XFS (so wie auch andere Deitsysteme) aus zumindest drei (bzw. 4) Komponenten besteht, von denen jede ihre eigenen Versionsnummenrn hat: (1) das On-Disk-Format, (2) der Kerneltreiber, (3) die xfsprogs und (4) das Handbuch.^[1] --Liebeskind (Diskussion) 10:02, 4. Nov. 2024 (CET)Beantworten

1. ↑ https://ftp.ntu.edu.tw/linux/utils/fs/xfs/docs/xfs_filesystem_structure.pdf