XFS und 2.6.17

Hallo Leute,


ich poste hier den Hinweis, dass Benutzer mit XFS im System beginnend mit
2.6.17-rcX eventuell in ihrer fstab die "nobarrier"-Option hinzufuegen wollen,
um das von 2.6.16 gewohnte Schreibtempo bei vielen Metadaten-Updates (z.B.
Entpacken/Kopieren der Kernelquellen) beizubehalten.

Standardmaessig ist nun naemlich barrier on (vorausgesetzt dass die Hardware
mitmacht), und das hatte bei mir zunaechst extreme Verwirrung erzeugt.

http://lkml.org/lkml/2006/5/22/278

jengelh schrieb:

Hallo Leute,


ich poste hier den Hinweis, dass Benutzer mit XFS im System beginnend mit
2.6.17-rcX eventuell in ihrer fstab die "nobarrier"-Option hinzufuegen wollen,
um das von 2.6.16 gewohnte Schreibtempo bei vielen Metadaten-Updates (z.B.
Entpacken/Kopieren der Kernelquellen) beizubehalten.

http://lkml.org/lkml/2006/5/22/278

Zum Vergrößern anklicken....

Hallo,

ich wäre damit sehr, sehr vorsichtig, denn das ist nach meinen eigenen Erfahrungen und allem, was ich bislang zu dem Thema weiß, bei eingeschaltetem WriteCache ziemlich gefährlich. Ich hatte auf einem IBM ThinkPad T23 innerhalb einer Woche drei XFS-Dateisystem-Crashes mit Kernel 2.6.16.4 und 2.6.16.11. Nähreres erkläre ich in diesem Blog-Eintrag:

http://open.teamix.net/node/208

Wer also Barriers ausschaltet, sollte auch den WriteCache ausschalten, aber da sollte XFS mit Barriers und aktiviertem WriteCache dann doch schneller sein, da dann der WriteCache nur dann auf die Platte rausgeschrieben wird, wenn dies für die Konsistenz des Dateisystems erforderlich ist.

Hintergrund für all dies: XFS muss wie andere Journalling-Dateisysteme sichergehen können, dass bestimmte Daten auf Platte geschrieben werden, bevor es weitere Daten schreibt:

http://oss.sgi.com/projects/xfs/faq.html#wcache

Meine Bitte daher: Bitte vor einer solchen Empfehlung an andere immer entsprechend recherchieren. Das vermeidet böse Überraschungen.

Eine weitere Empfehlung mit mir: Vorsicht bei SWS2 + XFS + CONFIG_REGPARM mit Kernel 2.6.15.7. Das ist mir diese Woche ganz gehörig um die Ohren geflogen! Die Root-Partition war ein Totalschaden und sogar die Home-Partition hat ein klein wenig abbekommen. Bedenklich, wenn ich sehe, dass bei 2.6.17 CONFIG_REGPARM standardmäßig aktiviert sein soll. Nun vielleicht sind die Probleme mittlerweile gefixt.

SWS2 hat zumindest auch für einen anderen Anwender mit CONFIG_REGPARM nicht funktioniert: http://kerneltrap.org/node/3070

Mein Fazit aus alledem: Es erscheint mir oft sinnvoller, lieber auf ein paar Prozent Performance zu verzichten, als sich einen Haufen potentieller Probleme ins Haus zu holen. So sehr ich auch ein Spielkind bin , aber dafür mach ich ja regelmäßig Backups.

PS: Ich benutze Debian Linux, aber darauf wollte ich dann doch mal antworten.

Grüße,

Hallo,

eine Idee noch, um XFS bei metadaten-intensiven Operationen zu bescheunigen:

You may be able to combat this by switching to version 2 log format
(see the xfs_db version command in the _very_ latest xfs_db, as of a
few days ago, which allows this switch to be made on an unmounted fs).
Then you will be able to use larger incore log buffers, and this
should reduce the impact the barriers have (fewer, larger log IOs, so
fewer barriers).

Zum Vergrößern anklicken....

(Nathan Scott, http://lkml.org/lkml/2006/5/22/278)