Zahlreiche Fehler: Scrub, Web-GUI und Timeouts SATA-Port

[hok]

Hallo User,

bin heute leider auf Probleme gestoßen - diverse Fehler treten mit meinem Server auf.
1. Problem:
im LOG ist am 26.12. das erste mal dieser Timeout-Fehler zu sehen:

Code:

Dec 26 00:24:19 hok-server kernel: ahcich4: Timeout on slot 15 port 0
Dec 26 00:24:19 hok-server kernel: ahcich4: is 00000000 cs 00000000 ss 01ff8000 rs 01ff8000 tfd 40 serr 00000800
(...)
Dec 26 10:50:32 hok-server kernel: ahcich4: Timeout on slot 0 port 0
Dec 26 10:50:32 hok-server kernel: ahcich4: is 00000000 cs 00000003 ss 00000000 rs 00000003 tfd c0 serr 00000000

Laut LOG die zugehörige Platte:

Code:

ada4 at ahcich4 bus 0 scbus4 target 0 lun 0
ada4: <SAMSUNG HD501LJ CR100-10> ATA-8 SATA 2.x device

###############
EDIT// Ein Lösungsansatz steht ein in dem Posting danach (fyysh) Ich werde es beobachten
###############

2. Problem
Inkonsistenzen bzgl. Namen der ZFS Datasets und Laufwerksbezeichnungen in der GUI und tatsächlich im System

Ich habe am 29.12. ein neues ZFS-Volume angelegt, bestehend aus einer neuen Festplatte. Darauf ein ZFS-Datensatz erstellt.
Nun haben sich beim Booten alle Laufwerke um einen Zähler verschoben, da das neue Laufwerk an einem neuen SATA-Controller hängt, ada0 zugewiesen bekommen hat und alle bestehenden Laufwerke demzufolge einen Zähler höher bekommen haben.

"zpool status" gibt alles richtig aus - in der GUI stehen ebenso die Namen richtig, wenn ich "Zeige Festplatten" aufrufe. Gehe ich jedoch auf "Edit " einer Festplatte, dann steht in dem Fenster oben unter Name noch die alte Zuweisung - also z.B. statt ada4 ada3)

Kann das Probleme machen?

#############
EDIT// Nach 2 Reboot war das Problem verschwunden.
#############


3. Problem
Scrub - Fehlermeldung

Der gestrige scrub hat einen Fehler in einem Pool gemeldet (es ist nicht der Port und nicht die Platte von Problem 1 - aber derselbe Pool):

Code:

zpool status:
(...)
  pool: Datenpool2
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-9P
 scrub: scrub completed after 1h7m with 0 errors on Fri Dec 30 09:30:59 2011
config:

	NAME        STATE     READ WRITE CKSUM
	Datenpool2  ONLINE       0     0     0
	  raidz1    ONLINE       0     0     0
	    ada4p2  ONLINE       0     0     0
	    ada5p2  ONLINE       0     0     0
	    ada6p2  ONLINE       3 2.55K     0

errors: No known data errors
(...)

Dazu steht im LOG:

Code:

Dec 30 09:22:40 hok-server kernel: ahcich5: Timeout on slot 26 port 0
Dec 30 09:22:40 hok-server kernel: ahcich5: is 00000000 cs 38000000 ss 3c000000 rs 3c000000 tfd c0 serr 00000800
Dec 30 09:22:41 hok-server kernel: (ada6:ahcich5:0:0:0): lost device
Dec 30 09:22:41 hok-server root: ZFS: vdev I/O failure, zpool=Datenpool2 path=/dev/ada6p2 offset=270336 size=8192 error=6
Dec 30 09:22:41 hok-server root: ZFS: vdev I/O failure, zpool=Datenpool2 path=/dev/ada6p2 offset=497959575552 size=8192 

Das ist noch während scrub lief.
Smart und weitere Laufwerksangaben habe ich geprüft, die sind unauffällig.

In der GUI ist nun dieses Laufwerk, welches den scrubfehler hat, als "unbekannt" gelistet. Die Seriennummer als "unknown".
Über die Konsole bekomme ich aber alle diese Angaben und "zpool status" zeigt alle online. Will ich über die GUI "ZFS Infos" haben, wird "Fehler" gemeldet. Über die Konsole bekomme ich aber die Infos.

###############
EDIT// Hilfe wie Pkt. 1 bzw: Ich habe meinen ganzen Server stromseitig umgebaut. Als ich nämlich bei laufendem Betrieb im inneren versehentlich eine Molexverbindung leicht berührt habe, hörte ich die Platte runterfahren...
Ich habe nun alle HDs in Racks, jeweils 4 an einem verlöteten Stromanschluß.
###############

4. Problem:
Die neue Festplatte am neuen Controller hat via "zpool status" ihren üblichen Namen "verloren" und wird mit der UUID angezeigt:

Code:

pool: Datenpool4
 state: ONLINE
 scrub: scrub completed after 0h0m with 0 errors on Fri Dec 30 11:11:09 2011
config:

	NAME                                          STATE     READ WRITE CKSUM
	Datenpool4                                    ONLINE       0     0     0
	  gptid/b5c3fee7-3222-11e1-878c-001b21525190  ONLINE       0     0     0

errors: No known data errors

Warum?

################
EDIT// Hier bin ich, mehr blind in meinem schlechten Englisch, auf einen Tip in einem US Forum gestoßen:

in der loader.conf diese 2 Zeilen hinzugefügt:

Code:

kern.geom.label.gptid.enable=0
kern.geom.label.gpt.enable=0 

################


Ich hoffe, ich habe halbwegs verständlich geschrieben. Kann mir jemand helfen das alles zu deuten?

Gruß
hok

 

[fyysh]

Hi hok,

Ich hatte ähnliche Probleme mit FreeNAS 8. Du solltest zunächst den AHCI Timeout loswerden und dann schauen, was noch übrig bleibt.

Ich hatte dieses Problem vermutlich wg. den WD's, die ich verwende.
Die Lösung war in der /boot/loader.conf die Zeile

Code:

vfs.zfs.txg.timeout="5"

Aufzunehmen.
Für Infos, was das macht, siehe hier: http://wiki.freebsd.org/ZFSTuningGuide

Damit wurde ich meine AHCI Timeouts los und auch alle anderen damit verbundenen/dadurch verursachten Probleme.


In FreeNAS 8.0.3 kannst du diese Tunable direkt im GUI unter "Loaders" definieren.

In FreeNAS kleiner als 8.0.3 muss du das über die Konsole machen.

Code:

ssh user@deine-freenas
su
mount -uw /
nano /boot/loader.conf  # ganz am ende vfs.zfs.txg.timeout="5" einfügen, speichern und raus mit ctrl+x -> y -> enter 
mount -ur /
exit

Hoffe es hilft.

 

[hok]

Hallo fyysh,

ich komme von einer Reise, daher erst jetzt: vielen Dank für deine wirklich hilfreiche Anleitung!
Ich habe alles so gemacht und werde das mal beobachten...

Beste Grüße
h.

 

[bubulein]

Moin,

wegen der Zuweisung der Devicenodes( ada0, ada1) würde ich erstmal Wachsamkeit walten lassen. Man kann nie wissen wo diese Werte später mal zu Unheil führen können. Ich würde den Pool exportieren, und wieder importieren, das sollte das Problem eigentlich lösen.

-Christian