RootForum Community

Mit welchen Optionen ist das betroffene Dateisystem denn gemounted? ReoBack führt AFAIR doch die Sicherung letztlich mit tar durch - kannst Du denn manuell mit tar irgendwas von dem Dateisystem einpacken, ohne dass es zu dem beschriebenen Fehler kommt? Oder ist am Ende das FS vielleicht sogar zu voll, wenn ReoBack zu viele/große temporäre Dateien erzeugt?

Hm, XFS geht eigentlich nicht so leicht hops - also jedenfalls nicht dadurch, dass man viel drauf rumliest oder -schreibt. Nach Deinen Schilderungen würde ich auch eher auf die Hardware tippen - müssen aber nicht unbedingt die Platten sein, könnte auch am Controller liegen. Das Zusammentreffen mit reoback ist wohl eher Zufall, wenn ein von Hand gestarteter tar-Job nicht zum Knall führt.

Hast Du schon mal einen extended Test mit smartctl gemacht? Vielleicht verrät der schon etwas mehr...

Moin,

ich bin auf folgendes gestoßen:

David Chinner wrote:FWIW, I see iSCSI and DRBD are in use on your machine. In the past,
XFS on top of either of these two transports would randomly suffer
from freespace btree corruptions which were not reproducable on
normal local block devices. So the cause of your problem may not be
XFS at all....

Diese Antwort von David Chinner legt nahe, dass btree-Corruptions (wie in Deinem Fall) bei iSCSI und DRBT schon in anderen Fällen aufgetreten sind, ohne dass eine Ursache zweifelsfrei ermittelt werden konnte.

http://www.google.com/webhp?hl=en#q=XFS ... source=lnt
Es ist zumindest kein seltenes Problem und tritt zudem auf diversen Architekturen und unter verschiedenen OS auf. Deutet also auf einen reinen XFS-Bug hin, der wohl sehr schwer zu debuggen ist :/