# XFS kaputt nach Stromausfall

## tuxthekiller

Ich wollte aMule emergen, lief ne ganze Zeit, bis meine Mutter reinkam und den Strom ausgestellt hat. Beim naechsten Start hat er wegen dem FS gemeckert, da habe ich die LiveCD genommen und wollte fsck.xfs ausfuehren-nix. Dann habe ich xfs_repair gefunden. Damit gings erst auch nicht wegen dem Superblock, -T drangemacht, wie er gesagt hat. Also die Logdatei ist futsch. Am Ende bricht er dann immer ab.

Fehlermeldung:

xfs_repair: read failed: Input/output error

cannot read inode 92472704, disk block 43349952, cnt 32

Aborted

Ist jetzt alles kaputt oder kann ich das FS noch retten? Start ging und geht nachdem ich das mit dem Superblock gemacht habe. Aber da kommen beim updaten des Portache-Caches I/O-Fehler und wenn ich bestimmte Dateien oeffnen will(aus dem Cache), kommt auch ein I/O-Fehler. Ich hoffe die Fehlerbeschreibung war gut.  :Smile: 

----------

## l3u

Ich denk mal, da hast du schlechte Karten. Deswegen benutz ich nicht XFS ... steht ja sogar im Handbuch, daß das mit Stromausfall nicht umgehen kann ...

----------

## hoschi

 *Quote:*   

> Portache-Caches I/O-Fehler

 

Portage-Cache?

XFS ist ein stinkfaules Filesystem, der schreibt kleine Dateien zum Teil erst nach dreißig Sekunden um schneller arbeiten zu können. 

Gerade das Kleinvieh erzeugt viel Mist und bremst alles (außerdem defragmentiert das FS schnell wenn man ständig an kleinen Dateien was ändert), deswegen hat XFS auch so eine "schlechte Performance" bei kleinen Dateien, bis sich XFS mal zu einer Schreiboperation bequemt kann für ein Andoriden eine Ewigkeit vergehen  :Very Happy: 

Da ist überhaupt nichts schlimmes dran, kill den Inhalt "/usr/portage" und führe ein "emerge sync" aus.

Viel Spass

PS: Viele nutzen wegen Portage "kleinem Design-Fehler" mit dem tausenden Minidateien gerne Reiser4, aber im Grund ist das eher ein schmutziger Workaround, als eine Lösung.

----------

## tuxthekiller

Hab ich schon gemacht. Allerdings habe ich einen runtergeladen Tree und entpackt. Der Fehler ist in /var/cache/blalala/portage/

EDIT: Ist XFS also ein FS fuer die Datenpartition?

----------

## mkr

Ich benutze auf den Workstations reiserfs, weil ich das für "normale" Systeme für das beste FS halte (schnell mit kleinen Files, verträgt mal einen Stromausfall).

Lediglich die Datenpartition auf dem Server (400 GB, vorallem Movies, durchschnittliche Dateigrösse ca. 500 MB) ist XFS. Der Server hängt an einer USV.

----------

## l3u

Nicht, daß ich jetzt hier die übliche Reiser-XFS-ext3-wasweißichwas-Diskussion vom Zaun brechen will ... aber man hat halt unter Linux, insbesondere, wenn man ständig irgendwelchen Kram kompiliert, sehr viel mit tausenden, winzigkleinen Dateien zu tun (--> allein der Kernel!). Liegt also nur bedingt an dem besch...eidenen System, das Portage (derzeit noch?) hat.

Also Ist (zumindest für mich) ein Dateisystem, das gut mit kleinen Dateien umgehen kann, das Dateisystem der Wahl; sprich: Reiser.

----------

## Lenz

 *Libby wrote:*   

> Nicht, daß ich jetzt hier die übliche Reiser-XFS-ext3-wasweißichwas-Diskussion vom Zaun brechen will ...

 

Hehe, komisch nur, dass solche Vorfälle wie von tuxthekiller beschrieben in den typischen Flame-Threads angeblich nur bei ReiserFS auftreten. XFS sei anscheinend "bombensicher" und Reiser sei das sog. "ReißwolfFS" -- so das Image.

Zu unrecht, wie ich finde. Sowas kann einfach mit jedem FS passieren, egal ob Reiser, Reiser4, ext3, XFS, NTFS, FAT32 (lol)... Komplettbackup ist mir sicherer als mich auf's FS zu verlassen. Das würde ich dir, tuxthekiller, an's Herz legen. Dann ist dein System in 10 Min wieder flott, sollte mal was sein.

P.S.: Ich verwende einen Mix auf ext2, ext3, reiserfs, reiser4, ntfs und fat32 und hatte mit jedem der genannten schon irgendwann mal solche Probleme.

----------

## nic0000

XFS ist sehr gut geeignet und ich habe damit duchweg positive Erfahrungen gemacht. Es ist ein stabiles und schnelles FS für den SERVER Bereich. Dafür ist es sehr gut geeignet und optimiert. Ebenso wird es auf verschidenen Platformen unterstützt und bietet eine Mege kommerziellen Support. Ob es jetzt im Server Berriech besser als ext3, Reiser etc. ist hängt wieder von speziellen Einsatzzweck und den Vorlieben/Erfahrungen der Admins ab. 

XFS ist aber devinitiv kein Workstation FS, es sei denn diese hängt an einem USV (und selbst dann würde ich es nicht empfehlen) 

Jetzt darüber zu debatieren ob es jetzt gut/schlecht/scheller/langsamer bzw. hochnäsig ist einfach fehl am Platz denn es ist für etwas anderes gemacht worden..

Wenn ich mit einem Porsche mein Feld pflüge, dann darf ich mich nicht wundern das das Auto schmutzig/kaputt/langsamer ist. Ich nehme wohl eher einen Tracker dafür, bin auf der Autobahn dann langsamer. Einen Superporschetracker kann es vielleicht auch geben, der ist dann aber zu groß und frist zu viel sprit. Eine "optimale" Lösung die alles abdeckt gibt es einfach nicht und wird es nicht geben.

Für die Workstation halte ich ext2/3 sowie reiserFS geeignet und ausreichend erprobt. Um XFS einzusetzen ist eine USV nun mal Pflicht und für einen profesionellen Server ein geringer Kostenfaktor.

----------

## sewulba

 *nic0000 wrote:*   

> XFS ist sehr gut geeignet und ich habe damit duchweg positive Erfahrungen gemacht. Es ist ein stabiles und schnelles FS für den SERVER Bereich. Dafür ist es sehr gut geeignet und optimiert. Ebenso wird es auf verschidenen Platformen unterstützt und bietet eine Mege kommerziellen Support. Ob es jetzt im Server Berriech besser als ext3, Reiser etc. ist hängt wieder von speziellen Einsatzzweck und den Vorlieben/Erfahrungen der Admins ab. 
> 
> XFS ist aber devinitiv kein Workstation FS, es sei denn diese hängt an einem USV (und selbst dann würde ich es nicht empfehlen) 
> 
> Jetzt darüber zu debatieren ob es jetzt gut/schlecht/scheller/langsamer bzw. hochnäsig ist einfach fehl am Platz denn es ist für etwas anderes gemacht worden..
> ...

 

Jetzt bin ich doch ein wenig verwirrt!   :Confused:  Ich habe XFS auf einer 74GB Seagate Cheetah Platte am Laufen. Diese Platte hat schon mindestens 15 Stromausfälle überlebt (gab in unserem Haus ein Leitungsproblem) und keine USV hier. Die Platte wird rege benutzt. ICH habe noch nie mir XFS Probleme bekommen. Ehrlich nicht, obwohl ich es bei manchen Stromausfällen im falschen Moment echt hätte verstehen können. Dagegen Reiser4 hat bei MIR schon zu dermaßen Problemen geführt, dass ich mindestens noch 2 Jahre warte bis ich mal wieder probiere. 

PS.: Momentan verwende ich ext2, ext3, XFS und das normale erbprobte ReiserFS.  :Shocked: 

Sewulba

----------

## Anarcho

Könnten wir nicht wenigstens EINMAL in einem Thread der etwas mit einem FS zu tun hat diese Diskussionen lassen? Das hilft dem OP überhaupt nicht.

Hier kommt doch immer das gleiche: Ich hab mit FS XY keine Probleme, dafür aber mit FS WQ und umgekehrt. Mittlerweile weiss es hier jeder.

----------

## hoschi

Jedes Dateisystem hat seine Stärken und Schwächen.

Ich bin kein Fan von Reiser4, weil ich die Kernelpolitik nachvollziehen kann und andererseits nicht viel mit kleinen Dateien zu tun habe (und da zählt der einmalige Start von Gnome eben nicht mir rein). Ich nutze dagegen XFS auf meine Laptop, es läuft stabil und schnell.

Trotzdem sehe ich die Vorteile von Reiser4, und ich glaube auch nicht jede Horrorgeschichte.

Genau so wenig bei XFS, ich hatte tatsächlich mal einen Systemausfall mit Folgen: Verlust eine kurz vorher geänderten xorg.conf 

Es war nicht der einzige Spontanausfall, also kann ich den Verlust verkraften - "cp /home/~/System/xorg.conf /etc/X11/xorg.conf"  :Rolling Eyes: 

Wenn man wirklich sicher fahren will, und doch modern sein will, dann soll man einfach EXT3 wählen. An der Wahl, da sind wir uns einig(?), ist wohl nichts falsches daran. Der Rest fällt unter die Freiheit die uns Linux gewährt, dämliche FS-Flamewars *grummel*

----------

## tuxthekiller

Die Diskussionen bringen jetzt auch nichts mehr. In 2 Jahren installier ich Linux neu und dann mit EXT3. Ob da jetzt ne kleine Fehlermeldung kommt ist nicht so schlimm.  :Confused:   Obwohl natürlich nicht optimal. Wieso schafft xfs_repair nicht, einfach die Partition zu reparieren? Gibt es da ein besseres Tool?

----------

## NightDragon

So Jungs, ich gebe auch mal meinen Senf dazu.

(autsch... hab ich schon gesagt das Angina weh tut?)...

Na zum Thema:

Fast alle Dateiysteme sind anpassbar (schreibcache, blockgröße, journal, usw...)

Sprich. Wieviel gecacht wird was das Journal alles macht usw... ist einstellbar.

Wer da beim Standard bleibt und nie mit den optionen arbeitet, darf auch nicht jammern.

ich verwende für alle meine root-systeme reiserfs 3.6

Für RAID Und Wechselplassten XFS

für Portage und /boot ext3 bzw. auch ext2.

Jo. Zum. Daten verlust.

Meine lieben Systeme haben ein Problem, ich muss sie wegen meine experminetierlust viel abwürgen, reseten, vom Strom nehmen usw...

Auf keinem der Systeme, ich wiederhole auf KEINEM, hatte ich bis jetzt einen der Datenverlust der problematisch gewesen wäre.XFS hat keine Dateisystemfehler, reiser läuft auch einwandfrei (mein notebook wäre sonst schon lange im Arsch).

Und meine Wechselplatten? na... also da hätte XFS (ja ich habe auch ganz viele kleine Dateien dort --> Webserver) bis jetzt auch nix zu jammern gehabt.

manchmal sind auch einfach die platten schrott und die controller, die im zuge ihres letzten stromimpulses scheiße bauen.

----------

## nic0000

 *sewulba wrote:*   

> Jetzt bin ich doch ein wenig verwirrt!   Ich habe XFS auf einer 74GB Seagate Cheetah Platte am Laufen. Diese Platte hat schon mindestens 15 Stromausfälle überlebt (gab in unserem Haus ein Leitungsproblem) und keine USV hier. Die Platte wird rege benutzt. ICH habe noch nie mir XFS Probleme bekommen. Ehrlich nicht, obwohl ich es bei manchen Stromausfällen im falschen Moment echt hätte verstehen können. Dagegen Reiser4 hat bei MIR schon zu dermaßen Problemen geführt, dass ich mindestens noch 2 Jahre warte bis ich mal wieder probiere. 
> 
> PS.: Momentan verwende ich ext2, ext3, XFS und das normale erbprobte ReiserFS. 
> 
> 

 

@sewulba

Oh ja, nur weil du keine Probleme hattest, können wir jetzt davon ausgehen das die Entwickler es für genau diesen Zweck entwickelt haben. *lachaus*

Ich habe meine Informationen aus einem XFS-Whitepaper und gehe davon aus das die Entwickler am besten wissen wieso sie etwas empfehlen. 

Es kann sein das es sich geändert hat, aber ich glaube das kaum. 

Ich finde das Papier dazu nicht aber es gibt ja google wenn es jemand genau wissen will. 

Es geht hauptsächlich um die massive Nutzung von Speicher und Optimierung der tatsächlichen Zugriffe auf die Datenträger und es wurde davor EINDRINGLICH gewarnt XFS ohne eine USV oder anderen Sicherstellung der Stromversorgung zu betreiben. 

Die Entwickler waren sich schon durch aus der Risiken der von ihnen vorgenommenen Optimierungen bewusst, ist der Benutzer das nicht, so droht genau das weshalb dieser Thread geöffnet worden ist. Ich halte mich daran und habe keine Probleme bis jetzt. Wer sich jetzt nicht daran hält und Probleme bekommt soll nicht sagen XFS ist aber schlechter als XYZ sondern sich nächstes mal besser informieren wie die einzelnen Sachen zu betreiben sind und gegebenfalls etwas für seinen Verwendungszweck empfohlendes benutzen.

@NightDragonc

Du hast vollkommen Recht, aber wenn ich mir diesen Thread so anschaue, dann sind die meisten eher auf dem Try&Error Prinzip unterwegs. 60% Sind Hörensagen oder Subjektive Einschätzungen aus eigenen Erfahrungen ohne Vergleichswerte. 

Ich möchte nicht wissen wie die Tipps zu den richtigen Einstellen der einzelnen FS dann wohl aussehen und vorallem wie sie belegt werden.

"Meine Mamma findet den Server jetzt viel schneller als deinen" 

"Mein Papa ist Feuerwehrmann und findet MEIN Laptop ist viel absturzsicherer als dein Server eingestellt"

Kindergarten

----------

## l3u

Naja, aber zumindest sind wir uns doch einig, daß XFS für Server- und Hochlastbetrieb geschrieben worden ist und nicht für einen Desktop, oder?

----------

## nic0000

 *Libby wrote:*   

> Naja, aber zumindest sind wir uns doch einig, daß XFS für Server- und Hochlastbetrieb geschrieben worden ist und nicht für einen Desktop, oder?

 

Selbstverständlich.  :Wink: 

Falls das nicht aus meinen Beitrag herauszulesen ist, dann entschuldige ich mich für meine unklare Formulierung.

----------

## l3u

War ne rhetorische Frage ;-)

----------

## sevo

 *nic0000 wrote:*   

> 
> 
> Es geht hauptsächlich um die massive Nutzung von Speicher und Optimierung der tatsächlichen Zugriffe auf die Datenträger und es wurde davor EINDRINGLICH gewarnt XFS ohne eine USV oder anderen Sicherstellung der Stromversorgung zu betreiben. 

 

Sprichst du da das alte SGI-Whitepaper zum Thema IDE-Festplatten-Schreibcaches an? Die muß man in der Tat ausschalten - das gilt mit identischen Konsequenzen aber auch für jedes andere Journaling Filesystem, denn deren Integrität über Stromausfälle hinweg ist davon abhängig, daß definierte Schreibreihenfolgen eingehalten werden. Und festplatteninterne Caches können (zumindest mit IDE-Platten ohne NCQ) die physikalische Schreibreihenfolge und damit die Integrität des Filesystems stören. Grundsätzlich sind aber bei Journaling FS Filesystemschäden auch durch Mißhandlung schwerer zu erzeugen als unter EFS bzw. ext2 - in Cluster-Filesystemen wird die Integrität durch jeden Abbruch beim Schreiben zwangsweise zerstört. 

XFS hat zwar ein verglichen mit Cluster-Filesysteme hohes Risiko, bei einem Stromausfall größere Abschnitte an Daten zu verlieren, da nur komplett abgeschlossene Vorgänge im Log nach dem Neustart commited werden. Aber das Filesystem selbst wäre davon nicht betroffen, sondern nur die Dateiinhalte - es ist entweder ist der ganze Vorgang im Journal und wird damit rekonstruiert, oder garnichts. Das ist allerdings Absicht - es kann zwar ein größeres Volumen verlorengehen, aber was geschrieben ist, besteht zuverlässig aus einem konsistenten Zustand, und nicht aus kaputten teilmodifizierten Dateien. 

Wenn bei Stromausfällen oder einem unsauberen Herunterfahren mit einem Journaling-FS mit WAL (wie XFS und JFS) nicht nur Dateiänderungen verlorengehen, sondern das Filesystem selbst beschädigt wird, ist das entweder ein Bug oder liegt an Ursachen unterhalb des Filesystems (sprich Kernel, Platten, Controller, Bus), wie den genannten Festplatten-Schreibcaches.

Gruß Sevo

----------

## nic0000

 *sevo wrote:*   

> Sprichst du da das alte SGI-Whitepaper zum Thema IDE-Festplatten-Schreibcaches an? 

 

Kann schon sein das wir das selbe Dokument meinen, es war gut umfangreich und ich habe nicht alles gelesen., aber das Teil hat sich auch mit dem eigenen Cachen beschäftigt. 

Zur damaligen Zeit hatten die Festplatten maximal 2MB FIFO Cache, selbst das kann schon ordentlich Probleme machen, aber wir reden hier bis zu mehreren Hundert MB die das XFS als Schicht darüber verwalten bzw. cachen kann. 

 *sevo wrote:*   

> XFS hat zwar ein verglichen mit Cluster-Filesysteme hohes Risiko, bei einem Stromausfall größere Abschnitte an Daten zu verlieren, da nur komplett abgeschlossene Vorgänge im Log nach dem Neustart commited werden. Aber das Filesystem selbst wäre davon nicht betroffen, sondern nur die Dateiinhalte - es ist entweder ist der ganze Vorgang im Journal und wird damit rekonstruiert, oder garnichts. Das ist allerdings Absicht - es kann zwar ein größeres Volumen verlorengehen, aber was geschrieben ist, besteht zuverlässig aus einem konsistenten Zustand, und nicht aus kaputten teilmodifizierten Dateien. 

 

OK, ich habe vielleicht bisschen übertrieben  :Cool: , aber generell besteht die Wahrscheinlichkeit bei XFS mehr Daten zu verlieren als bei Ext3/Reiser weil es nun mal mehr cacht. 

Deshalb finde ich es auch in Ordnung pauschal zu sagen: "XFS=USV sonst höheres Risiko Datenverlust zu erleiden."

 *sevo wrote:*   

> Wenn bei Stromausfällen oder einem unsauberen Herunterfahren mit einem Journaling-FS mit WAL (wie XFS und JFS) nicht nur Dateiänderungen verlorengehen, sondern das Filesystem selbst beschädigt wird, ist das entweder ein Bug oder liegt an Ursachen unterhalb des Filesystems (sprich Kernel, Platten, Controller, Bus), wie den genannten Festplatten-Schreibcaches.

 

Das Risko wird ja auch immer bleiben. Das ist ja auch der Grund warum Linux im Highend ServerBereich nicht immer eingesetzt wird sondern andere erprobte UNIX Systeme auf Besonderer Hardware (zB. Akkugepufferte Caches im SCSI/FC Controller).

(Endlich fängt der Thread an interessant zu werden)

----------

## sevo

Wie gesagt, die scheinbar volumenmäßig größeren Datenverluste mit XFS relativieren sich, wenn man bedenkt, daß Daten dafür nicht inkonsistent verloren werden - zum Schreiben geöffnete Dateien werden unter korrekten Rahmenbedingungen niemals beschädigt, sondern bleiben immer entweder im alten oder im neuen Zustand erhalten. 

Mit ATA-Treibern unter Linux gab es da aber auch noch gewisse Probleme mit deren Caching-Verhalten, wenigstens bis in die frühen 2.6er war das teilweise fehlerhaft und konnte Konsistenzprobleme produzieren - was bei ohnehin Crash-inkonsistenten Filesystemen egal war, aber den Sinn besserer Journaling FS torpediert. Im Zweifelsfall SCSI benutzen...

Gruß Sevo

----------

## sschlueter

 *tuxthekiller wrote:*   

> 
> 
> Fehlermeldung:
> 
> xfs_repair: read failed: Input/output error
> ...

 

Scheint mir, als ob das nicht am FS, sondern an der Platte liegt.

Gab es da gleichzeitig Kernel-Meldungen die Platte betreffend?

----------

## hoschi

Zum Thema USV: Die Batterie im Laptop erfüllt diesen Zweck auch hervorragend, womit man den Begriff "High-End-Server mit USV" etwas gedehnt hätte  :Very Happy: 

Das wichtigste ist einfach dass die Metadaten nicht beschädigt werden, falls doch - "Wo ist den das Backup?". 

Weh tuts dagegen immer, wenn die Daten noch nicht auf der Platte sind, oder eben noch nicht im Journal. Und da hält XFS und auch andere Dateisysteme kleinere Daten länger im Cache...

Die Welt (der Dateisysteme) ist nicht perfekt, Datenverlust wird man immer haben.

Gott, gib uns Festplatten ohne beweglich Teile, die bei Samsung(?) sollen mal in die Hufe kommen   :Twisted Evil: 

----------

## flash49

Ich überspringe jetzt mal die ganzen "mein-fs-ist-besser-als-dein-fs" Kommentare und geh mal zur Ausgangsfrage zurück:

 *tuxthekiller wrote:*   

> 
> 
> Fehlermeldung:
> 
> xfs_repair: read failed: Input/output error
> ...

 

Was mir hier auffällt ist, dass xfs_repair sagt, dass es einen Block nicht lesen kann und nicht etwa, dass es den nicht reparieren kann!

Hast du schon überprüft, ob deine Festplatte noch in Ordnung ist (z.B. mit badblocks)?

Edit:

Ich hätte doch nicht alles so großzügig überspringen sollen, sschlueter hat das auch schon gefragt...

----------

