Absturz/Reboot: Zfs, Rsync, rm.... Bug oder Change Operator?

F

fred123

Well-Known Member
Basis: Backup, usw. -Server PC-BSD/FreeBSD 9.1, ZFS Z1/Mirror. Clients 9.x 10.x PC-Freebsd Laptops.
.
Funktion: Backup per Rsync (Script) auf den Server.
.
Problem: Rsync sichert home/USER ins Backup- Verzeichniss auf dem Server.
(Verschieben auf andere Zpools ändert nichts)
.
In .../Backup/usr/home/USER/bin sind Sym-Links auf Client-/usr/pbi/*..., die mitgesichert werden. Es wird nur der link nicht der Inhalt gesichert!
.
Da geht problemlos!
.
Beim Rollback (löschen alter Sicherungen) wird diese Sicherung "heiss"!
.
rm /*/Backup/USER/bin/* provoziert ein reboot. Zugriff auf einen Link der ins Leere zeigt!
.
Löschen des Verzeichisses .../Backup/usr/home/USER/bin (das mit dem sym Links) auf den Server führt unweigerlich zum Reboot des Servers! Ist wiederholbar!
.
Der Link ist nicht eindeutig zu identifizieren! Je nach Backup löst ein anderer Link den "Panic-Absturz" aus. Einzeln mit unlink usw. sind diese Links zu löschen!
.
Log:
(da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:25,0 (Logical unit not supported)
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
(da0:umass-sim0:0:0:0): lost device - 0 outstanding, 2 refs
usw.
Mehr ist nicht aus den normalen Logs zu holen
..
.
Frage: Was ist da falsch?
.
Hat ZFS, rsync, rm.... oder der Operator eine Macke:-) Habe ich was übersehen?
.
Hat jemand eine Idee?
.
Gruss
Fred
.
(Auch eine nativ BSD Installation mit rsync (incl. SymLinks) per Hand bring gleiche Ergebnisse:-((
ZFS? )
 
Zuletzt bearbeitet:
Wie sieht denn der Pool überhaupt aus und was sagt die dmesg?

Mein Bauch sagt erst mal "kaputte Hardware", aber das kann auch Quatsch sein.
 
Hoi,
schau mal ob der / die zfs pools und datasets ok sind. Prüf oifach au mal die HDDs wo da dran hängen und in den Pools werkeln. Ein Update auf mindestens 9.2 mit aktuellem Patchlevel wäre sicherlich auch nicht unbedingt die blödeste Idee.

Gruß Bummibär
 
Hallo,
Bummibaer schrieb:
Hoi,
schau mal ob der / die zfs pools und datasets ok sind. Prüf oifach au mal die HDDs wo da dran hängen und in den Pools werkeln. Ein Update auf mindestens 9.2 mit aktuellem Patchlevel wäre sicherlich auch nicht unbedingt die blödeste Idee.

Gruß Bummibär
Zum Vergrößern anklicken....
.
Das war auch der 1. Gedanke, habe ich schon hinter mir. Hard- und Software komplett getauscht. Stresstest des alten Bords und Platten negativ. Links lassen sich normal erzeugen und löschen OHNE Probs/Panic....
.
Der /die Pools/Platten sind OK ohne Befund. Sowohl "Smartd", wie auch "Zpool srub pool" bringen keinerlei Fehlermeldungen.
.
Der Panic ist auf Reserve-hardware anderes Board/ andere Platten auch mit aktuellem 9.2 reproduzierbar!
.
Gruss
Fred
.
Dmesg:
ZFS filesystem version 5
ZFS storage pool version 28
...
ada0 - ada8 normal,
ada0-ada2 ZFS-Mirror
ada3-ada8 ZFS-Z1
 
Also, generell war die Kombination aus ZFS und rsync in den frühen Jahren von ZFS problematisch. rsync erzeugte Zugriffsmuster, die ZFSs Cache-Verwaltung ans Limit brachten. Das wiederum führte zur Arbeitsspeicherfragmentierung, was eher früher als später eine "kmem_map too small"-Panic nach sich zog. Allerdings sind solche Probleme lange behoben. Die Änderungen, die heute in ZFS eingehen, beheben so obskure oder komplexe Bugs, dass kaum ein Anwender sie treffen wird. Meine Arme-Leute-Replikation mit 3 Nodes läuft z.B. unter FreeBSD 9.2, hat derzeit ~10TiB Daten und ~31.000 Snapshots auf dem zpool. rsync synchronisiert jede Stunde. Seit September letzten Jahres habe ich noch keinen Crash gesehen. Nicht einmal auf der schwächsten Node mit nur 2GB RAM.

Code: 
da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:25,0 (Logical unit not supported)
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
(da0:umass-sim0:0:0:0): lost device - 0 outstanding, 2 refs
Das wäre ein Hardware-Versagen. Die Festplatte oder was auch immer das ist hotpluged sich aus. Allerdings sagst du, dass der zpool auf ada0 bis ada8 liegt und das Problem auch auf anderer Hardware auftaucht. Also könnte man auch das ausschließen.

Daher bleiben eigentlich nur 2 Möglichkeiten:
- Du triffst tatsächlich einen dieser obskuren Bugs in ZFS. In diesem Fall würde ich den Kernel (den Rest des System braucht man für einen kurzen Test nicht unbedingt anzufassen) auf 11-CURRENT updaten und schauen, ob die Probleme auch dort auftreten.
- Die Metadaten des Pools sind geschrottet. Das soll an sich nie passieren, aber z.B. kaputte Hardware kann sowas auslösen. Passiert es sind die Auswirkungen, wie auch bei anderen Dateisystemen, eklig und es hagelt Panics. In diesem Fall würde es helfen die Daten manuell (d.h. nicht per zfs send) in einen neuen Pool zu kopieren.

Ich würde nun erstmal schauen, ob es irgendwelche Einträge in /boot/loader.conf zu ZFS gibt und sie entfernen. Anschließend schauen, ob ich die Panic-Ausgabe bekomme. Und wenn es per schlechter Handy-Kamera abfotografiert ist. Dann eine Mail an freebsd-fs@ schreiben, die Panicausgabe angehängt oder in Fall von Fotos verlinkt. Die Entwickler freuen sich immer über Panics, denn nur so findet man Fehler im Code. Mehr als dich ignorieren können sie nicht.
 
Hallo
danke für die Anregungen und Tips.
werde versuchen einmal die Panic-Infos vom Bildschirm zu holen :-))
.
Mein Verdacht geht in Richtung: Nicht legale Links ins Leere, die in der Regel ja nicht angelegt, bzw.
nicht ohne die, bzw nur mit der Quelle gelöscht werden können.
.
Gruss
Fred
(der leider ein wenig Stress hat)
.
@Yamagi: Die /dev/da.... waren ein Fehler vor der Tastatur:-) Das sind Kartenslots die nicht belegt sind
und deswegen beim Booten nicht initialisiert werden :-) Sorry.
.
Metadaten sind OK. Tritt auch bei jungfräulicher Platte/anderem Boar auf neu aufgesetztem System reproduzierbar auf.
 
What? Symlinks ohne gültiges Ziel sind das Normalste der Welt und crashen _keinen_ Rechner.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben