Re: wie lese ich meine kerneldumps?

From: Peter <pmc(at)citylink.dinoex.sub.org>
Date: Mon, 7 Nov 2016 01:09:54 +0100

On Tue, Oct 18, 2016 at 09:57:22AM +0200, Oliver Fromme wrote:
! Moi'n Dag

Moin auch. :)

! Eine kleine Anmerkung ... (ich habe die Diskussion allerdings
! nicht bis ins Detail mitverfolgt)

Macht nichts. Die Sache entwickelt sich aber zu einem echten
Ärgernis, will meinen ich bin inzwischen mit meinem Latein am ende. :(

! Peter wrote:
! > [...]
! > Die Verdächtigen sind angeblich alle okay, nur eine SCSI im Raid ist
! > angeblich defekt - komischerweise klettern da die ECC Zähler wie wild
! > wenn ZFS drauf zugreift, wenn man aber mit einem normalen UFS drauf ist,
! > gibts keine ECC errors.
!
! Das kann an der Verteilung der Meta-Daten und den Usage-Pattern
! der verschiedene Dateisysteme liegen. Diese sind ja bei UFS
! ("klassisch" mit direktem Überschreiben) und ZFS (Copy-on-write)
! sehr unterschiedlich.
!
! Gut möglich, dass die Platte irgendwo (z.B. ganz hinten) eine
! oder mehrere "schwache" Spuren hat, die aber bei UFS zunächst
! gar nicht verwendet werden, bei ZFS aber schon.

Gute Idee. Ich glaub da aber nicht dran, weil
1. die Fehlerrate dafür ungeöhnlich hoch ist (~1000 pro GB read),
   d.h. es müsste (bei 8k blocksize) rund 1% der reads auf
   schlechte Sektoren treffen,
2. ZFS nur die vordere Hälfte der Platte nutzt, und
3. diese Fehlerrate scheinbar von einem Tag auf den anderen in
   genau dieser konstanten Menge angefangen hat (soweit sich aus
   den smart-Meldungen in den gespeicherten daily.log zurückrechnen
   ließ.

Das sieht für mich nicht nach schlechten Sektoren aus, sondern
nach irgendeinem systemischen Fehler, sei es in der Elektronik
der Platte oder irgendwo in der Software/Firmware.

Wenn es tatsächlich ein systemischer Fehler ist, dann tritt der
nicht plötzlich aus heiterem Himmel auf, sondern dann muss sich
irgendein Parameter geändert haben.
Und einen solchen Parameter gibt es tatsächlich: an dem Tag, auf
den ich den Anfang der ECC-Fehler zurückrechnen kann, hab ich
den Write-Cache für die Platten eingeschaltet.
Und jetzt wirds wieder richtig bizarr: wenn ich den Write-Cache
testhalber wieder ausschalte, werden ECC-Errors dennoch weiterhin
akkumuliert (auch nach Power-Off/Reboot).

Weiter im Debugging:
Ich hab mir mal alle die paar dutzend panic-dumps, die ich
inzwischen hab, angeschaut. Herausgekommen ist: der, den ich
zunächst angeschaut (und hier tw. gepostet) hab, ist untypisch.
85% der panics kommen von genau derselben Stelle in
cam/scsi:dastart(): dort fehlt offenbar ein Buffer in den Ketten.
Soweit ich mich in den Symbolen durchhangeln konnte, dass der
zugehörige Drive ersichtlich wird, ist das jedesmal ein anderer -
zufällig verteilt auf die drei Drives im RAID.

Also folgere ich: die ursprüngliche Annahme, dass der Fehler
ursächlich mit dem eingebauten SSD zu tun hat, dürfte falsch sein.
Vielmehr dürfte irgendein Problem in der SCSI-Mechanik sein.
(Dahin deutet auch die Merkwürde mit den TCQ. Und dahin deutet
auch, dass die Panics dann kommen, wenn das SCSI-Raid ordentlich
was zu arbeiten hat - zB beim VACUUM)

Es kann aber nicht am Controller liegen (hab ich getauscht),
nicht am Kabel (hab ich getauscht), nicht am Mainboard (hab ich
getauscht), und dass alle drei Platten plötzlich denselben
Fehler liefern, ist auch irgendwie unwahrscheinlich.

Die einfache Lösung wäre jetzt, diese alte SCSI-Mechanik einfach
wegzuschmeissen und was zeitgemäßes zu verwenden. Aber das wär
unsportlich - und ausserdem mag ich den Sound. Neuere Platten
hört man ja nicht mehr. :(

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 07 Nov 2016 - 03:13:16 CET

search this site