Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

XFS und 2.6.17

Alles rund um die Systemverwaltung, die Administration und Konfiguration Eures Linuxsystems

Moderator: Moderatoren

Antworten
jengelh
Guru
Guru
Beiträge: 4039
Registriert: 20. Nov 2004, 17:42
Kontaktdaten:

XFS und 2.6.17

Beitrag von jengelh » 25. Mai 2006, 14:05

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

Werbung:
helios42
Newbie
Newbie
Beiträge: 2
Registriert: 10. Jun 2006, 21:44
Kontaktdaten:

Re: XFS und 2.6.17

Beitrag von helios42 » 10. Jun 2006, 22:01

jengelh hat geschrieben: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
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,
Martin Steigerwald

helios42
Newbie
Newbie
Beiträge: 2
Registriert: 10. Jun 2006, 21:44
Kontaktdaten:

Beitrag von helios42 » 10. Jun 2006, 22:08

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).
(Nathan Scott, http://lkml.org/lkml/2006/5/22/278)
Martin Steigerwald

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste