2017-11-02 4 views
1

Wir aktualisieren unsere Anwendung von RHEL6.5 ext4 auf RHEL7.3 XFS. Wir haben festgestellt, dass bei einem Neustart des XFS-Dateisystems (von der Systemkonsole aus - iLO) einige unserer Dateien (die alle paar Sekunden auf die Festplatten geschrieben werden) auf null Byte gekürzt werden. Nicht nur unsere Anwendung, sondern sagen wir, dass wir die Ausgabe von einem Befehl in eine Datei umleiten, indem wir ">" verwenden, diese Dateien verschwinden nach dem kalten Neustart. Wir sind uns der Empfehlung bewusst, dass wir eine Fync machen. Aber was ist unser Code in Java? Was ist mit den Fällen aus unseren Python-Skripten?XFS RHEL7.3 Kaltstart, Dateiabkürzung

Jetzt sind wir im Dilemma, ob mit ext4 oder XFS zu bleiben. XFS hat Vorteile und wäre unsere erste Präferenz. Und wir können nicht glauben, dass der Rest der Welt sich dessen nicht bewusst ist. Entweder ist das bei RHEL etwas Spezifisches (wir sehen ein ähnliches Problem in RHLE6.5 https://bugzilla.redhat.com/show_bug.cgi?id=845233) oder das ist das erwartete Verhalten moderner FileSystems?

Antwort

1

Sowohl Java als auch Python bieten Zugriff auf die fsync Operation in ihren E/A-Bibliotheken, also ist dies nicht wirklich eine Entschuldigung, aber ich verstehe, was Sie meinen.

Allerdings ist der Schlüssel ext4/XFS Unterschied in diesem Bereich in der Regel etwas anderes. Eine gerade

echo contents > file 

manchmal hinter einer Null-Länge-Datei lassen auch bei ext4, vor allem, wenn die schriftlichen Inhalte mehr als nur ein paar Bytes. Was ist garantiert auf ext4 (mit einer Standardkonfiguration) zu arbeiten, ist dies:

echo contents > file.new 
mv file.new file 

Mit ext4-mit-defaults, wird dies nie hinter einem lassen teilweise geschrieben file (nur file.new möglicherweise unvollständig). XFS ist in dieser Hinsicht anders, da der Inhalt vor dem Umbenennen fsync ed sein muss.

In 2014, Eric Sandeen proposed a patch to align the XFS behavior with what ext4 does, aber es war nicht gut erhalten zu der Zeit und es wurde nicht zusammengeführt. Vielleicht haben sich die Gezeiten seitdem verändert und ein neu vorgeschlagener Patch wäre heute akzeptabel. (Ich sehe keine Flush im aktuellen Code, aber ich bin kein XFS-Entwickler.)

Wenn dies Ihre Migration zu XFS blockiert, sollten Sie unbedingt ein Support-Ticket einreichen. Auch wenn es für den Kunden eigentlich keine Option ist, vom Upstream-Kernel abzuweichen, sind solche Kundenwünsche immer wichtig.

+0

Danke, Florian. Macht es sehr deutlich. Auf ext4 haben wir nodellalloc in unseren Mount-Optionen und wir sind nicht in der Lage, das fehlerhafte Verhalten zu reproduzieren. Unser Problem beim Hinzufügen von fsync ist unsere riesige Codebasis. Wir können Tausende von Stunden ausgeben, ohne sicher zu sein, dass unsere Abdeckung 100% beträgt. Wir haben bereits einen Fall mit Red Hat Support eröffnet. Die Standardantwort lautet: "Es ist kein Red-Hat-Problem. Das gibt Ihnen XFS. Fügen Sie fsync hinzu oder löschen Sie es." Ihr Link von Erics Patch könnte uns helfen, sie ein wenig mehr zu pushen. Ich bin jedoch sehr skeptisch. – Avita

Verwandte Themen