Diskussion:XFS (Dateisystem)
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit
oder --~~~~.Datenkonsistenz
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)
- 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.)
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.)
- "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.
Nachteile
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)
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?].
Ausformulierung
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)
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)
Variable Blockgrößen
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.)
Datenverlust statt Crash
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.)
(De)Fragmentierung
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)
- 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)
- Korrekt! (nicht signierter Beitrag von 92.217.12.187 (Diskussion) 19:45, 17. Jul. 2022 (CEST))
Nachteile von XFS
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)
- 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)
"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))
- 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)
- 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))
Exbibyte vs. Exabyte
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)
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)
- 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.
Dateinamenlänge vs. Pfadnamenlänge
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.)
Widerspruch?
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))
Blockgrößen
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))
- 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)
Lemma
Was bedeutet „XFS“ ausgeschrieben?
--Konrad – 14:53, 24. Mär. 2010 (CET)
- 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)
- X steht -vermutlich- für eXtended... --84.175.235.111 11:03, 1. Nov. 2015 (CET)
Defekt auf ARM
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)
- 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)
Linux 2.4?
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))
- wird sind mittlerweile bei 5.x ;)
Der Artikel müsste in einen chronologischen Überblick umgestaltet werden
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)
- Fang an damit ;) --92.217.12.187 20:22, 17. Jul. 2022 (CEST)
