# zahlreiche Prüfsummen-Fehler… rsync kaputt?

## TheSmallOne

Hallo Forum,

ich habe hier ein etwas merkwürdiges Verhalten. Da ich mehrere Gentoo-Rechner habe, synche ich den Portage-Tree einmal aus dem Netz auf einen meiner Rechner (A), und alle anderen Maschinen holen sich den Tree dann von dort ab.

Jetzt habe ich einen Rechner (B), bei dem es gelegentlich dazu kommt, dass der Portage-Tree fehlerhaft ist. Ich erhalte also zahlreiche Fehlermeldungen wegen unstimmiger Checksummen.

Da frage ich mich allerdings: Wie kann das überhaupt passieren? Portage verwendet doch rsync um die Dateien zu synchronisieren, oder nicht? Rsync sollte doch eigentlich seinerseits auch Prüfsummen der Dateien verwenden, um Änderungen oder Übertragungsfehler zu erkennen.

Wenn ich versuche den Fehler durch ein erneutes emerge --sync zu beheben werden die problematischen Dateien nicht angefasst. Erst wenn ich sie lösche, werden sie erneuert.

Ist möglicherweise mein rsync-binary kaputt?

----------

## Josef.95

Hm, ist eventuell reiserfs im Spiel?

Siehe zb auch im https://forums.gentoo.org/viewtopic-t-998538.html

----------

## TheSmallOne

Hm, tatsächlich handelt es sich bei der Portage-Partition auf dem betroffenen Rechner um ein reiserfs. Wusste gar nicht mehr, dass ich das überhaupt irgendwo einsetze.   :Laughing: 

Wenn es „nur“ ein Filesystem-Problem ist, dann beruhigt mich das zumindest ein wenig. Obwohl ich es dennoch seltsam finde: Ich war der Meinung, dass rsync die Dateien selbst mit Checksummen prüft. Es hätte dem Programm also meiner Ansicht nach spätestens beim nächsten emerge --sync auffallen müssen, dass die Dateien corrupted sind und eine Neuübertragung stattfinden müssen.

----------

## py-ro

rsync benutzt Standardmäßig keine Checksums, das muss man explizit anfordern. Selbst das hätte aber nicht geholfen, da es diese nur zum bestimmen von Dateien zum Update verwendet und nicht nach dem schreiben erneut prüft. (Ja, beim übertragen selbst generiert es checksums für chunks der Dateien)

Bye

Py

----------

## Klaus Meier

Auf gar keinen Fall mehr Reiser benutzen. Finde es jetzt gerade nicht auf die Schnelle, aber da gar es vor einiger Zeit Artikel, selbst Suse rät von Reiser ab. Es wird einfach nicht mehr ausreichend supportet, um an aktuelle Entwicklungen angepasst zu werden.

Auf Pro Linux wurden vor einiger Zeit auch mal verschiedene Filesysteme getestet, wenn auch mit einem sehr alten Kernel, und da ergab sich auch, dass aktuelle Filesysteme von der Performance her deutlich besser sind. Aktuell kann man nur zu btrfs, ext4 und xfs raten.

Man sieht ja gerade, dass eingetreten ist, was man befürchtet hat.

----------

## kernelOfTruth

ähem nein - reiserfs an sich hat nie Daten zerstört, korrumpiert oder derartiges (zumindest für mich   :Laughing:  )

wenn man sich anschaut, wie massiv der Code und die Kommentare umstrukturiert wurden kann man sich nur fragen, ob das wirklich notwendig gewesen ist (mag es ja über längere Sicht)

der Fix wurde ja schon 2 Tage nachdem der 3.16.y Kernel released wurde gepostet, nur hat es sich massiv hingezogen, bis es in 3.16 drin war - 

da fragt man sich, warum es nicht automatische Tests mit Prüfsummen für Dateisysteme gibt,

damit nach größeren Änderungen zumindest "grob" die Integrität gewährleistet ist

falls sowas auftaucht sollte man so gut wie alles liegen lassen und das direkt als Notfall-Hotfix veröffentlich bzw. posten

es geht ja schließlich um Datensicherheit

Genau dieses Vorgehen und Vernachlässigen von reiserfs hat mich schon vor einigen Monaten dazu gebracht, es (außer auf /boot und ab und an in /var/tmp und /usr/portage) nicht mehr für wirklich kritische

Daten einzusetzen

----------

## musv

Wenn jetzt Rechner A sowas wie 'ne Buildmaschine ist, könntest du den Portage auch einfach in ein RAM-Laufwerk reinschmeißen und das dann per NFS  verteilen. Mach ich so ähnlich. Portage liegt bei mir auf der NAS. Alle Rechner mounten dann den Portage und die Distfiles per NFS. Damit erspar ich mir jegliches syncen der einzelnen Rechner. eix-update ist das einzig Notwendige auf jeder Kiste. 

Nachteil: Die Programminstallation über NFS-Portage dauert ein ganzes Stück länger.

----------

## Klaus Meier

 *kernelOfTruth wrote:*   

> ähem nein - reiserfs an sich hat nie Daten zerstört, korrumpiert oder derartiges (zumindest für mich   )

 

Ok, das glaube ich dir gerne. Bin da gerade am suchen, finde es aber nicht. Suse sind ja diejenigen, die hinter Reiser gestanden haben. Und die verwenden es ja schon seit einiger Zeit nicht mehr als StandardFS und sie haben davon abgeraten, es einzusetzen. Weil sie genau das vorausgesehen haben, was jetzt passiert ist.

Pro Linux hat dazu schon vor über einem Jahr geschrieben:

```
Reiser3 präsentierte sich als schlecht gewartet und in vielen Punkten ziemlich langsam. Auch bei diesem System war im Gegensatz zum letzten Test die Barrier-Option gesetzt, womit es wohl schlecht klar kommt. Reiser3 sollte nicht mehr verwendet werden. 
```

----------

## kernelOfTruth

genau   :Sad: 

Das musste unweigerlich passieren, da sie wohl die einzigen noch sind, die das aktiv supporten und weiter"entwickeln" (also die Änderungen von den Kernel Subsystemen einpflegen)

Lange Zeit hatte ich gehofft, dass Reiser4 es schaffen würde in Linus' Baum aufgenommen zu werden,

weil es wirklich effizient und performant lief - in 99% ebenfalls kein Datenverlust - Resets, Hardlocks überstand es ebenfalls wunderbar

Daraus wird wohl nix: es wird zwar von Freiwilligen + Edward Shishkin (erfreulicherweise) weiterentwickelt

es fehlt aber schlicht die Manpower (vgl. Btrfs, wo jetzt z.B. Filipe Manana massiv Bugs gefixt werden) um einige langausstehende Bugs auszumerzen, und auch damit es dem schnellen Entwicklungszyklus vom "Stable"-Kernel (also jede neue Kernelversion) fehlerfrei und zuügig angepasst werden kann

----------

## Klaus Meier

Das Problem von Reiser war schon immer der Support. Kaum war Reiser3 im Kernel, hat sich Hans Reiser nicht mehr drum gekümmert und sich auf Reiser4 gestürzt. Und es war erst mal niemand da, der sich um Reiser3 gekümmert hat. Deshalb ist ja auch Reiser4 nie in den Kernel gekommen. Weil sich dann wieder irgendwer hätte drum kümmern müssen. Und um den Code vom Hans Reiser reißt sich keiner...

----------

## l3u

 *Quote:*   

> Reiser3 sollte nicht mehr verwendet werden.

 

Dem ist nichts hinzuzufügen. Warum sollte man auch ein so altes und nicht mehr gewartetes Dateisystem noch verwenden wollen, wenn es neuere und vor allem bessere Alternativen gibt? Damals™ war ReiserFS mal toll, aber die Zeiten ändern sich eben …

----------

## musv

 *kernelOfTruth wrote:*   

> Daraus wird wohl nix: es [Reiser4] wird zwar von Freiwilligen + Edward Shishkin (erfreulicherweise) weiterentwickelt

 

Echt?

Ich hatte es bis 2.6.38 verwendet. Das war die letzte Kernelversion, für die ich noch einen Patch gefunden hatte. In den vorherigen Versionen hatte ich auch diverse Mailkontakte mit Edward, da ich irgendwelche Fehlermeldungen gleich direkt an ihn geschickt hatte. Aber schon bei 2.6.38 kam der Patch auch erst sehr verzögert. Ich glaub, da war beim Kernel schon die 2.6.39 oder die 3.0 veröffentlicht. Spätestens hatte ich nichts mehr von Reiser4 gehört. Bin damals nach einiger Wartezeit auf BTRFS umgestiegen.

 *Klaus Meier wrote:*   

> Deshalb ist ja auch Reiser4 nie in den Kernel gekommen. Weil sich dann wieder irgendwer hätte drum kümmern müssen.

 

Das ist nicht korrekt. Bei Reiser3 wurde der Support in der Tat eingestellt, da der Hans den Umstieg auf Reiser4 "beschleunigen" wollte. 

Reiser4 kam aber nicht in den Kernel, da der Code nicht den Richtlinien der Kernelentwickler entsprach. Der Hans weigerte sich, seinen Code an die Richtlinien anzupassen.

Btw. hab grad auf der Homepage gesehen, dass es für 3.15 tatsächlich einen Patch gibt. Ist eigentlich schade, ich mochte Reiser4. Aber zurück zu Reiser4 werd ich nicht mehr gehen. Das Patchen war mir irgendwo dann zu aufwendig. Weiß jemand, wie's mit SSD-Optimierung aussieht bei Reiser4?

----------

## mv

 *l3u wrote:*   

> Warum sollte man auch ein so altes und nicht mehr gewartetes Dateisystem noch verwenden wollen, wenn es neuere und vor allem bessere Alternativen gibt?

 

"Nicht mehr gewartet" ist ein solides Argument und der Grund weshalb ich auch schon vor langer Zeit schweren Herzens auf ext4 gewechselt habe.

Aber "alt" und "besseere Alternativen"? Das erste ist gar kein Argument,und für das Zweite sehe ich im Moment noch nichts. Ob BTRFS irgendwann mal besser sein wird - zumindest was ich über die Stabilität und vor allem das Verhalten bei vollen Festplatten gehört habe, ist nicht ermutigend. Meine Datenplatten sind zumindest meistens ziemlich voll, und ich sehe nicht ein, einen Overhead einzukaufen, nur um ein diesbezüglich mangelhaftes Filesystem benutzen zu können.

Es ist sehr schade, dass Reiser4 tot ist - das war sehr vielversprechend.

----------

