XFS hat eigentlich nur einen kleinen, aber nicht ganz unwichtigen, Nachteil :
XFS stellt nur die Integrität des Dateisystems und nicht der Daten sicher. Das heißt, das man z.B. nach einem Stromausfall oder Totalabsturz zwar ein sauberes Dateisystem hat, der Inhalt von noch nicht fertig geschriebenen Dateien aber nicht mehr konsistent ist.
Anstatt den Ursprungszustand der Datei per Journal wieder herzustellen, füllt XFS fehlende Daten einfach mit Nullen auf. Dadurch hat die Datei zwar die gleiche Größe wie vorher, enthält aber meistens nur noch unbrauchbaren Datenmüll (Sehr toll, wenn dadurch eine wichtige Konfigurationsdatei zerstört wird, die zum Booten des System notwendig ist). Das ist auch der Hauptgrund warum ext3 in der Standardeinstellung langsamer als andere Dateisysteme ist. Dort werden erst die Daten und dann das Journal geschrieben.
XFS ist ein wunderbares Dateisystem für Rechner an denen eine USV hängt oder von dem man 100% weiß das alle Treiber stabil sind und das System nicht ins Nirvana schicken. Für alle anderen Systeme ist es in meinen Augen zu riskant.
Wenn man grub auf einem XFS-Dateisystem zu installieren versucht, kommt eine Warnung, dass das Booten fehlschlagen könnte. Bei allen Systemen, die ich getestet habe, scheiterte das Booten in der Tat. Die Installer einiger Distributionen lassen es mittlerweile nicht mehr zu, dass man eine Partition mit XFS zur Bootpartition macht.
> XFS ist ein wunderbares Dateisystem für Rechner an denen eine USV hängt > oder von dem man 100% weiß das alle Treiber stabil sind und das System > nicht ins Nirvana schicken. Für alle anderen Systeme ist es in meinen > Augen zu riskant.
Ich habe reichlich Crash-Tests mit XFS gemacht und keine Probleme festgestellt. XFS als riskant zu bezeichnen, ist und bleibt FUD. Wenn im Moment eines Stromausfalls gerade Daten geschrieben wurden, weiß man bei keinem Dateisystem, welche davon auf der Platte gelandet sind. Beim nächsten Mount bringt sich XFS wieder in einen konsistenten Zustand und gut ist.
Es macht einen Unterschied, ob du GRUB in den Bootsektor einer XFS-Partition installieren willst oder ob /boot auf XFS liegt. Ersteres geht in der Regel schief, aber die meisten dürften GRUB ohnehin in den MBR schreiben.
in den Standardeinstellungen istr ext3 schneller, weil es auf ein wichtiges Sicherheitsfeature verzichtet. Die Standardeinstellungen von xfs sind bekanntermaßen langsam.
"XFS stellt nur die Integrität des Dateisystems und nicht der Daten sicher. Das heißt, das man z.B. nach einem Stromausfall oder Totalabsturz zwar ein sauberes Dateisystem hat, der Inhalt von noch nicht fertig geschriebenen Dateien aber nicht mehr konsistent ist."
Hmm, aber unter ext3 ist die Datei auch nicht komplett, oder? Sondern liegt halt in der Länge vor, in der sie bis zum Ausfall geschrieben war, aber mit Hinweis auf den fehlenden Teil?
Mit fsck.ext3 kriegste den fehlenden Teil aber doch auch nicht her, oder?
nein. Und da ext3 barriers per default nicht benutzt und bei den heutigen cache-größen kann ext3 nichtmal garantieren, daß das fs sauber ist. Wenn die Hälfte des journals es noch nichtmal auf die Platte geschafft hat, dann ist das schon bitter. Aber für manche Leute (ext3 devs, Distris, ext3 Benutzer) ist Datensicherheit halt nachrangig.
Kannst du das mit den Barriers mal etwas genauer erläutern?
Die Manpage scheint mir im Prinzip genau das Gegenteil zu sagen von dem was du die Tage so schreibst, denn: Enables the use of block layer write barriers for writes into the journal and unwritten extent conversion. This allows for drive level write caching to be enabled, for devices that sup‐ port write barriers.
D.h. dank den Barriers kann der Plattencache [für die Journal writes] aktiviert werden. Das hiesse doch dass er bei den Barrierlosen writes deaktiviert ist (und ergo hier Ext3 benachteiligt worden wäre...; es aber keine Konsistenzprobleme nach einem Stromausfall hat (zumindest nicht wegen der Barriers))
Das hiesse doch dass er bei den Barrierlosen writes deaktiviert ist (und ergo hier Ext3 benachteiligt worden wäre...; es aber keine Konsistenzprobleme nach einem Stromausfall hat (zumindest nicht wegen der Barriers))
Das steht da nicht. Du musst schon selbst mittels hdparm o.ä. dafür sorgen, dass deine Festplatte keinen Write-Cache benutzt.
nein, mit barriers kann das fs sicher stellen, daß die Platte bestimmte Daten direkt auf den Platter schreibt und nicht im cache vermoddern läßt. Die caches sind so oder so an. Wenn das fs und die Platte (und das sind heutzutage eigentlich alle) barrier unterstützten kann das fs der Platte mitteilen, daß bestimmte Datensätze direkt auf die Platte geschrieben werden müssen, bevor irgendetwas anderes getan wird.
Die Gefahr mit cache und ohne barrier: das journal liegt zum großen Teil darin (oder andere wichtige fs-Strukturdaten) und schaffen es nicht mehr auf die Platte. Resultat: nach dem crash ist das fs beschädigt, Datenverluste wahrscheinlich. Wenn ein fs keine barrier unterstützt oder per default deaktiviert, sollte man auch den Festplattencache deaktivieren - was allerdings auch Leistung kostet. Und für viele FS ist barrier+cache schneller, als keine barrier+keine cache. ext3 unterstützt nun zwar barriers, aber weil dadurch die Leistung bei ext3 sehr stark einbricht, sind sie per default aus. Woraus man schließen kann: ext3 schert sich nicht um deine Daten.
XFS hat eigentlich nur einen kleinen, aber nicht ganz unwichtigen, Nachteil :
XFS stellt nur die Integrität des Dateisystems und nicht der Daten sicher. Das heißt, das man z.B. nach einem Stromausfall oder Totalabsturz zwar ein sauberes Dateisystem hat, der Inhalt von noch nicht fertig geschriebenen Dateien aber nicht mehr konsistent ist.
Anstatt den Ursprungszustand der Datei per Journal wieder herzustellen, füllt XFS fehlende Daten einfach mit Nullen auf. Dadurch hat die Datei zwar die gleiche Größe wie vorher, enthält aber meistens nur noch unbrauchbaren Datenmüll (Sehr toll, wenn dadurch eine wichtige Konfigurationsdatei zerstört wird, die zum Booten des System notwendig ist).
Das ist auch der Hauptgrund warum ext3 in der Standardeinstellung langsamer als andere Dateisysteme ist. Dort werden erst die Daten und dann das Journal geschrieben.
XFS ist ein wunderbares Dateisystem für Rechner an denen eine USV hängt oder von dem man 100% weiß das alle Treiber stabil sind und das System nicht ins Nirvana schicken. Für alle anderen Systeme ist es in meinen Augen zu riskant.
> XFS ist ein wunderbares Dateisystem für Rechner an denen eine USV hängt
> oder von dem man 100% weiß das alle Treiber stabil sind und das System
> nicht ins Nirvana schicken. Für alle anderen Systeme ist es in meinen
> Augen zu riskant.
Ich habe reichlich Crash-Tests mit XFS gemacht und keine Probleme festgestellt. XFS als riskant zu bezeichnen, ist und bleibt FUD. Wenn im Moment eines Stromausfalls gerade Daten geschrieben wurden, weiß man bei keinem Dateisystem, welche davon auf der Platte gelandet sind. Beim nächsten Mount bringt sich XFS wieder in einen konsistenten Zustand und gut ist.
Hmm, aber unter ext3 ist die Datei auch nicht komplett, oder? Sondern liegt halt in der Länge vor, in der sie bis zum Ausfall geschrieben war, aber mit Hinweis auf den fehlenden Teil?
Mit fsck.ext3 kriegste den fehlenden Teil aber doch auch nicht her, oder?
Und da ext3 barriers per default nicht benutzt und bei den heutigen cache-größen kann ext3 nichtmal garantieren, daß das fs sauber ist. Wenn die Hälfte des journals es noch nichtmal auf die Platte geschafft hat, dann ist das schon bitter.
Aber für manche Leute (ext3 devs, Distris, ext3 Benutzer) ist Datensicherheit halt nachrangig.
Die Manpage scheint mir im Prinzip genau das Gegenteil zu sagen von dem was du die Tage so schreibst, denn:
Enables the use of block layer write barriers for writes into
the journal and unwritten extent conversion. This allows for
drive level write caching to be enabled, for devices that sup‐
port write barriers.
D.h. dank den Barriers kann der Plattencache [für die Journal writes] aktiviert werden. Das hiesse doch dass er bei den Barrierlosen writes deaktiviert ist (und ergo hier Ext3 benachteiligt worden wäre...; es aber keine Konsistenzprobleme nach einem Stromausfall hat (zumindest nicht wegen der Barriers))
-Peschmä
Das steht da nicht. Du musst schon selbst mittels hdparm o.ä. dafür sorgen, dass deine Festplatte keinen Write-Cache benutzt.
Die Gefahr mit cache und ohne barrier: das journal liegt zum großen Teil darin (oder andere wichtige fs-Strukturdaten) und schaffen es nicht mehr auf die Platte. Resultat: nach dem crash ist das fs beschädigt, Datenverluste wahrscheinlich.
Wenn ein fs keine barrier unterstützt oder per default deaktiviert, sollte man auch den Festplattencache deaktivieren - was allerdings auch Leistung kostet. Und für viele FS ist barrier+cache schneller, als keine barrier+keine cache. ext3 unterstützt nun zwar barriers, aber weil dadurch die Leistung bei ext3 sehr stark einbricht, sind sie per default aus. Woraus man schließen kann:
ext3 schert sich nicht um deine Daten.