FreeBSD 8.1 daily crash

T

ThomasXYZ

Member
Hi@all,

ich bin der Neue ... und komm jetzt öfter ;)

Ok ... wie der Titel schon sagt habe ich hier ein kleines Problem ... dessen Ursache ich teilweise schon auf den Grund gekommen bin.

Der tägliche Crash findet jede Nacht gegen 3 Uhr statt und hängt mit dem dann gestarteten Cron Job (daily) zusammen.
Der Crash läßt sich aber auch tagsüber reproduzieren und zwar entweder mit find ( find /apool -ctime 3 ) oder mit du ( du -sh /apool )

Code: 
...
instruction pointer = 0x20:0xffffffff80ec682e
...
panic : page fault
...

Ein vollständiges Foto des Screens kann ich bei Bedarf nachreichen ...

Das System ist ein "alter" Dell PE 1800 mit 4GB RAM und 2x 500GB Platten die ich als Mirror für die zroot nutze
Bei der Installation bin ich nach folgender Anleitung vorgegangen:
http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror

Für den Datenpool (apool) habe ich 4x 1TB Seagate Platten an einem 3Ware 9650SE (raidz)

Erwähnen sollte ich vielleicht noch das ich dieses System als Backup Server nutze(n) (möchte) ... Der primäre Server ist ein Opensolaris 2009.06 von dem ich jede Nacht ein zfs send auf den Backup mache ...
Theoretisch nutzen beide ja zpool Version 14 ...

Bis auf die vier Daten-Platten habe ich praktisch alles schon getauscht bzw. die Platten sogar in ein völlig anderes System eingebaut ...

Merkwürdig finde ich das ein scrub z.B absolut fehlerfrei und problemlos durchläuft ... aber auch ein "grep -R test /apool" erzeugt diesen Crash ... habe ich gerade feststellen müssen ....

In zroot passiert das nicht ... wobei ich nicht sagen kann ob das nicht vielleicht an der Menge der Daten liegt ....

Ein googeln nach dem instruction pointer liefert keinen Treffer ... nm in /boot/kernel/* übrigens auch nicht.
Den Generic Kernel neu zu übersetzen hat auch nichts gebracht ...

Ich bin ratlos *grummel*

EDIT : Kleines Update ... Ich habe jetzt einmal unter FreeBSD ein neues FS unter apool erzeugt und ca 15GB mit rsync rein kopiert ... und nacheinander du, find und grep getestet ... kein Crash ... scheint also wirklich mit zfs send / receive zusammen zu hängen ....

Hat jemand eine Idee ?

Gruß

ThomasXYZ
 
Zuletzt bearbeitet:
Ist das die x64 Variante von FreeBSD?

In /boot/loader.conf schon irgendwelche ZFS Optimierungen eingetragen? Wenn nicht, mal folgende Optimierungsparameter ausprobieren:

vm.kmem_size="6G"
vfs.zfs.arc_max="2G"

(wobei dein Fehler jetzt nicht unbedingt auf ein kmem Problem schließen lassen würde)

Ist dein zfs send/receive eine direkte Spiegelung der Dateisysteme, oder sendest du alles in eine separate Datei?
 
Hi,

ja die Einträge in der /boot/loader.conf habe ich exakt so schon gesetzt.
Und es ist die x64 Variante.

Und ja es ist eine direkte Spiegelung des daily snapshots auf dem primären System

zfs send -R -i $LAST $NEW | /usr/bin/ssh $DESTINATIONHOST zfs receive -F -d $DESTPOOL

Wobei ich den ersten Datenbestand sogar rekursiv übertragen hatte ...

Wenn also in einem FS staff auf dem primären Server für jeden User ein eigenes FS erzeugt wurde habe ich auf dem FreeBSD Backup Server nur staff erzeugt und den rekursiven Snapshot (also auch alle orginal Snapshots) mit allen darunter liegenden Filesystems gesendet ...
 
Hm...dann hab ich auch keine Idee mehr...
Evtl. ein Problem zwischen BSD-ZFS und OSOL-ZFS?

Backup-Server auch mal mit OSOL ausprobieren? Wobei OSOL ja afaik keine 3Ware Controller unterstützt...hmmm
 
Also ... ich hatte vorher auf genau der gleichen Hardware Opensolaris (mit dem 3ware) .... beginnend mit 2009.06 Build 111b bis Build 134.

Die unterschiedlichen ZFS Versionen spielen dabei, soweit ich beobachtet hatte keine Rolle ... zpool Version 14 blieb auch in b134 14 ... und ZFS Version 3 blieb Version 3 *fg*

Man durfte nur auf dem b134 System(ZFS Version 4) kein FS anlegen und dann versuchen auf den b111b zu senden ...

Ich bin eigentlich nur wegen der unsicheren Zukunft von Opensolaris umgestiegen. Und da Nexenta mit seinem CIFS (nicht Samba) bei uns aus verschiedenen Gründen nicht zu gebrauchen ist, bin ich auf FreeBSD gekommen...
Zpool Version 14 und eine hinreichend aktuelle Version von Samba ließen mich hoffen ;)

Ich überlegt im Augenblick ernsthaft ob ich den Patch auf Version 15 testen soll !?!
Selbst ohne ein zpool upgrade könnte das evt. helfen ...
 
Ja...die Zukunft von Opensolaris...(Hoffnung ruht momentan auf Illumos und zukünftigen Forks).
An FreeBSD weiß man wenigstens, was man hat :-)

Die zpool und zfs bleiben auf Ihren Versionen, solange du nicht upgradest.
Ich vermute eher ein Problem zw. dem ZFS Code von FreeBSD und Opensolaris. Auch wenn beides auf der gleichen Basis beruht...ist bei FreeBSD doch einiges angepasst worden und wird letztendlich erst mit FreeBSD 9 komplett zur Opensolaris ZFS Version aufgeholt haben (afaik wg. Kernel-Beschränkungen).

Dir bleibt auch immer noch die Möglichkeit die ZFS dumps in Dateien zu schreiben (anstatt direkt ins FS), oder andere Backup-Strategien einzurichten.
 
Hmm,

Dir bleibt auch immer noch die Möglichkeit die ZFS dumps in Dateien zu schreiben (anstatt direkt ins FS), oder andere Backup-Strategien einzurichten.
Zum Vergrößern anklicken....

tja ... nur das dann auch kein Fallback möglich ist ... (zwar eher manuell ... aber immerhin )

Wie oben erwähnt tritt das Problem scheinbar nicht auf wenn ich die Filesystems unter FreeBSD selber erzeugt habe .... bliebe also der Versuch den Transfer nicht mit zfs send/receive sondern mit rsync durchzuführen und zusätzlich noch Snapshots auf dem Backup Server einzurichten ...

Dabei kann ich gleichzeitig testen ob ein cp oder mv auch den Crash verursacht *fg*
 
Hmm,

das wird ja immer mysteriöser ...

Also wenn ich in einem Filesystem bleibe und dort ein find, grep oder du mache stürzt das System nicht ab.

Wenn find und co aber das Filesystem während des Durchlaufs wechseln müssen kommt es beim 3-4 Wechsel zum Crash ... egal ob das Filesystem leer oder befüllt ist ...

Zum Test habe ich folgende Struktur erzeugt :

Code: 
zfs create apool/test
zfs create apool/test/home
zfs create apool/test/home/staff
zfs create apool/test/home/staff/userx

Dann habe ich nur "userx" mit Daten befüllt ... mein Home ist ca. 27GB groß.

Dann habe ich ein "find /apool/test/home/staff/userx -ctime -2" mehrfach laufen lassen -> kein Crash

Dann das find auf /apool/test/home/staff losgelassen -> kein Crash
Bei /apool/test/home kam dann der Crash

Als ich auf dem normalen Datenbestand den Test in .../home/staff durchgeführt habe lief er durch 3 Homeverzeichnisse ( also eigene Filesystems) und stürzte dann erst ab ?!?

Kann das vielleicht irgend jemand reproduzieren ???

Thx

ThomasXYZ
 
Keine Ahnung, was da nun mit geworden ist, aber das hier klingt sehr nach dem Problem:
Code: 
  Author: delphij                                                               
  Date: Sun Sep 12 06:19:35 2010                                                
  New Revision: 212490                                                          
  URL: http://svn.freebsd.org/changeset/base/212490                             
                                                                                
  Log:                                                                          
    MFC r212008, 212028, 212210: Vendor update to version 3.80.06.003 to        
    fix panic with ZFS under heavy I/O load.                                    
                                                                                
    PR:             kern/149968                                                 
    Submitted by:   LSI (Tom Couch)                                             
    Reported by:    Kai Kockro <kkockro web de>                                 
    Tested by:      Kai Kockro, jpaetzel
Ist nun in 8-STABLE :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben