[ZFS] Mirror degraded -> online ohne Plattentausch

Errorsmith

Errorsmith

Kompiliertier
Moin

Am Dienstag letzte Woche habe ich von zpool Status die Meldung bekommen das mein zpool "zroot" degraded ist: Eine der beiden SSD sei defekt. Ich hab dann eine neue SSD bestellt, die kam heute an. Eigentlich würde ich die gerne einbauen, aber:

1. Wie identifiziere ich die defekte SSD, beide SSD sehen identisch aus.
2. Bei Eingabe von "zpool status" erhalte ich das hier:
Code: 
  pool: zroot
 state: ONLINE
  scan: resilvered 1.48G in 0h0m with 0 errors on Fri Jan  3 15:43:11 2014
config:

  NAME  STATE  READ WRITE CKSUM
  zroot  ONLINE  0  0  0
  mirror-0  ONLINE  0  0  0
  gptid/fdfba098-5c42-11e3-8bbd-8c89a5c88ad4  ONLINE  0  0  0
  gptid/fe13b994-5c42-11e3-8bbd-8c89a5c88ad4  ONLINE  0  0  0

errors: No known data errors

Was ist hier passiert? Die SSD sind herkömmliche Consumer SSD, es handelt sich um zwei "KINGSTON 30GB SSDNow S200 SATA 3". Haben die Dinger - wenn auch in Grenzen - irgendwelche Reservesektoren o.ä. die nun aktiviert wurden?

3. Gibt es bei ZFS irgendein LOG mit dem ich herausfinden könnte, welche der SSD zwischenzeitlich "kaputt" war, so das ich die trotzdem tauschen kann? Irgenwie gefällt mir das nicht, das eine SSD sich einfach mal so "offline" meldet und ich würde die vielleicht präventiv tauschen, da ich die neue schon mal da habe.

4. Ich hatte auf den SSD je 4GB SWAP Partition, die habe ich nach der Ausfall-Meldung deaktiviert (swapoff) und aus der /etc/fstab genommen. Soweit ich weiß hat der Rechner die aber nie benutzt, da die 16GB RAM ausreichten. Gibt es da eventuell dennoch einen Zusammenhang?

Grüße,
errorsmith
 
Ein großes Problem bei günstigen SSDs ist, dass sie nicht anständig sterben können. Ich habe es schon so oft gesehen, dass SSD anfangen sich "seltsam" zu verhalten. Plötzlich Fehler, die dann wieder verschwinden. Sie hotpluggen sich aus, tauchen gleich danach wieder auf. Sie werden einfach grottigst langsam. Und so weiter. Sie nun zu identifizieren wird schwer, denn ZFS hat zwar ein Kommando-Log (zfs / zpool history), aber kein dauerhaftes Fehlerlog. Das Fehlerlog wird durch "zpool scrub" zurückgesetzt. Ich würde daher mal in der /var/log/messages nach ATA-Fehler schauen, oder vielleicht mit SMART herumstochern.

Zur Swap: FreeBSD swappt grundsätzlich alle Prozesse aus, die 24h nicht gelaufen sind. Das heißt, egal wie viel RAM du hast, es sammeln sich mit der Zeit immer ein paar Megabyte Kleinkram - ungenutzte Shells, schlafende Systemdienste wie getty, etc. - in der Swap an. Aber das hält sich in Sachen Last für die SSD in Grenzen, daher würde ich da nicht den Schuldigen suchen.
 
Hallo

Hast du ein "zpool scrub" durchgeführt? Leider habe ich jetzt auf die schnelle keine Idee aber vielleicht ein paar Punkte für das "hoffentlich nicht" nächste mal ;)

1) Ich erstelle auf den SSD/HD's die ZFS Partition mit der SN im Namen. z.B. hier eine Testmaschine in Virtualbox:
Code: 
=>     34  2097085    ada9  GPT  (1.0G)
       34  2097085  ada9p1  VB04f94e6f-p1-zfs  (1G)
Die SN kannst du dann von aussen ablesen oder ans Gehäuse schreiben.

3) Evtl. hilft dir "zpool history -il zroot". Sonst kenne ich kein Fehlerlog.
Ich habe bei mir hier etwas mit "devd" nachgeholfen. So schreibt mir "devd" eine Meldung per "logger" ins Log. Dazu musst du unter "/usr/local/etc/devd die Datei "devd.conf" anlegen oder bearbeiten:
Code: 
# zpool device removed
notify 10 {
        match "system"  "ZFS";
        match "type"    "resource.fs.zfs.removed";
        action "logger -p local0.crit 'ZPOOL: POOL DEGRADED!'";
        action "printf 'Service: ZPOOL\n  State: POOL DEGRADED!' | mail -s '** PROBLEM alert ** - from '$(hostname)' ZPOOL: POOL DEGRADED!' hostmaster@....";
};

4) Hier ist zu empfehlen, dass du aus den beiden SWAP Partitions einen Mirror mit "gmirror" erstellst und diesen in die "fstab" einträgst.
Code: 
root@vh6 ~ # gmirror status
       Name    Status  Components
mirror/swap  COMPLETE  ada0p2 (ACTIVE)
                       ada1p2 (ACTIVE)
-------------------------------------------------------------------------------------------------------------

root@vh6 ~ # cat /etc/fstab
#SWAP
#/dev/gpt/VBc9a9c854-p2-swap   none  swap  sw  0   0
#/dev/gpt/VB56bf9321-p2-swap   none  swap  sw  0   0
/dev/gpt/mirror-swap-p1 none  swap  sw  0   0



Gruss
 
Die Seriennummer bekommst du auch mit camcontrol raus.
Code: 
root@dolw17srv01:~ # camcontrol devlist
<ATA TOSHIBA DT01ACA3 ABB0>        at scbus0 target 0 lun 0 (pass0,da0)
<ATA TOSHIBA DT01ACA3 ABB0>        at scbus0 target 1 lun 0 (pass1,da1)
<ATA TOSHIBA DT01ACA3 ABB0>        at scbus0 target 2 lun 0 (pass2,da2)
<ATA TOSHIBA DT01ACA3 ABB0>        at scbus0 target 3 lun 0 (pass3,da3)
<ATA TOSHIBA DT01ACA3 ABB0>        at scbus0 target 4 lun 0 (pass4,da4)
<ATA TOSHIBA DT01ACA3 ABB0>        at scbus0 target 5 lun 0 (pass5,da5)
<Samsung SSD 840 PRO Series DXM05B0Q>  at scbus3 target 0 lun 0 (pass6,ada0)
<SAMSUNG SSD 830 Series CXM03B1Q>  at scbus4 target 0 lun 0 (pass7,ada1)

Und dann:
Code: 
root@dolw17srv01:~ # camcontrol identify /dev/ada0
pass6: <Samsung SSD 840 PRO Series DXM05B0Q> ATA-9 SATA 3.x device
pass6: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

protocol              ATA/ATAPI-9 SATA 3.x
device model          Samsung SSD 840 PRO Series
firmware revision    DXM05B0Q
serial number        S1ANNEAD632250Z
WWN                  50025385503ab39b
...

Gruß
Markus
 
Hi

Der Fehler trat auf während eines "scrub" Vorgangs. Danach habe ich kein scrub mehr laufen lassen und die Maschine so weit "geschont" wie möglich. Ich bin mir auch nicht sicher ob ein scrub mit der potentiell defekten SSD so sinnvoll wäre.

Die Labels wurden von bsdsetup so vergeben, ich habe da keinen Einfluss darauf gehabt. Zugegeben bin ich aber noch nicht auf diese Idee gekommen... Ich hätte in dem Rechner noch einen Pool, bei dem die Platten ebenfalls identisch sind. Kann ich die Label der Partitionen noch ändern ohne das der Pool auseinanderfällt? Swap werde ich "umbauen" auf einen gmirror wenn ich die SSD getauscht habe. Die Idee mit devd ist auch super, das werde ich ebenfalls übernehmen.

Ok, ein wenig "Gewühle später":
So wie es aussieht verlief das ganze so: Nachdem Der Fehler aufgetreten ist, habe ich swap abgeschaltet und die Maschine soweit erstmal in Ruhe gelassen. Am Freitag habe ich dann den Maschine heruntergefahren (in einem anderen Zusammenhang), anschließend wieder eingeschaltet. Dabei "kam" die SSD scheinbar wieder, sie taucht in /var/log/messages auf und darauf hin hat zfs den Pool ohne mein zutun oder mir Info darüber zu geben, wieder hergestellt.
Frage dazu:
Code: 
Jan  3 15:42:49 eisenschwein kernel: ahcich0: <AHCI channel> at channel 0 on ahci0
Jan  3 15:42:49 eisenschwein kernel: ahcich1: <AHCI channel> at channel 1 on ahci0
Jan  3 15:42:49 eisenschwein kernel: ahcich3: <AHCI channel> at channel 3 on ahci0
Jan  3 15:42:49 eisenschwein kernel: ahcich4: <AHCI channel> at channel 4 on ahci0
Jan  3 15:42:49 eisenschwein kernel: ahcich5: <AHCI channel> at channel 5 on ahci0
Ich habe tatsächlich Port 3 (wäre dann hier ahcich2) auf dem Board nicht angeschlossen. Deckt sich das tatsächlich zufällig mit den physischen Ports auf dem Board (1-6) Dann wüßte ich welche SSD es ist, nämlich die an ahcich1=Port2.

zpool history -il zroot gibt mir das da für Freitag aus:
Code: 
2014-01-03.15:42:49 [txg:529116] open pool version 5000; software version 5000/5; uts  10.0-BETA4 1000502 amd64 [on eisenschwein.localnet]
2014-01-03.15:42:54 [txg:529119] scan setup func=2 mintxg=9 maxtxg=529115 [on eisenschwein.localnet]
2014-01-03.15:43:11 [txg:529122] scan done complete=1 [on eisenschwein.localnet]

Was ich jetzt damit machen soll weiß ich nicht, ich werde die SSD auf jeden Fall tauschen.

Yamagi schrieb:
Ein großes Problem bei günstigen SSDs ist, dass sie nicht anständig sterben können. Ich habe es schon so oft gesehen, dass SSD anfangen sich "seltsam" zu verhalten.[...]Ich würde daher mal in der /var/log/messages nach ATA-Fehler schauen, oder vielleicht mit SMART herumstochern.
Zum Vergrößern anklicken....

Ich habe ein paar Timeouts in /var/log/messages:
Code: 
Jan  3 04:41:43 eisenschwein kernel: ahcich1: AHCI reset: device not ready after 31000ms (tfd = 00000080)
Jan  3 04:41:43 eisenschwein kernel: ahcich1: Poll timeout on slot 22 port 0
Jan  3 04:41:43 eisenschwein kernel: ahcich1: is 00000000 cs 00400000 ss 00000000 rs 00400000 tfd 80 serr 00000000 cmd 0000d617
Jan  3 04:41:43 eisenschwein kernel: (aprobe0:ahcich1:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Jan  3 04:41:43 eisenschwein kernel: (aprobe0:ahcich1:0:0:0): CAM status: Command timeout
Jan  3 04:41:43 eisenschwein kernel: (aprobe0:ahcich1:0:0:0): Error 5, Retries exhausted
Jan  3 04:41:43 eisenschwein kernel: ahcich1: Timeout on slot 22 port 0
Jan  3 04:41:43 eisenschwein kernel: ahcich1: is 00000000 cs 03c00000 ss 03c00000 rs 03c00000 tfd 80 serr 00000000 cmd 0000d617
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 30 f0 fc 2c 40 00 00 00 00 00 00
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): CAM status: Command timeout
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): Error 5, Periph was invalidated
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 08 58 20 2e 40 00 00 00 00 00 00
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): CAM status: Unconditionally Re-queue Request
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): Error 5, Periph was invalidated
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 08 c8 72 94 40 00 00 00 00 00 00
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): CAM status: Unconditionally Re-queue Request
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): Error 5, Periph was invalidated
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 68 20 fd 2c 40 00 00 00 00 00 00
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): CAM status: Unconditionally Re-queue Request
Jan  3 04:41:43 eisenschwein kernel: (ada1:ahcich1:0:0:0): Error 5, Periph was invalidated

Das ist aber eigentlich auch schon alles.
Heißt das, das die SSD auf jeden Fall defekt ist? Oder hatte die nur "Schluckauf" weil es halt ein nicht allzuteures Teil war? Das die Kabel "richtig" sitzen setze ich mal voraus, ich habe den Rechner vor einigen Wochen erst zusammengebaut. Smart gibt mir nicht allzuviel aus, das überrascht mich allerdings nicht wirklich, ich hab da eigentlich noch nie brauchbare Info bekommen bevor die Platte endgültig tot war.
Code: 
[root@eisenschwein ~]# smartctl -a /dev/ada1
smartctl 6.2 2013-07-26 r3841 [FreeBSD 10.0-BETA4 amd64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:  KINGSTON SS200S330G
Serial Number:  50026B7234064852
Firmware Version: S8FM05.1
User Capacity:  30,016,659,456 bytes [30.0 GB]
Sector Size:  512 bytes logical/physical
Rotation Rate:  Solid State Device
Device is:  Not in smartctl database [for details use: -P showall]
ATA Version is:  ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s
Local Time is:  Tue Jan  7 12:34:46 2014 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
  was never started.
  Auto Offline Data Collection: Disabled.
Self-test execution status:  (  0) The previous self-test routine completed
  without error or no self-test has ever
  been run.
Total time to complete Offline
data collection:  (  255) seconds.
Offline data collection
capabilities:  (0x1b) SMART execute Offline immediate.
  Auto Offline data collection on/off support.
  Suspend Offline collection upon new
  command.
  Offline surface scan supported.
  Self-test supported.
  No Conveyance Self-test supported.
  No Selective Self-test supported.
SMART capabilities:  (0x0003) Saves SMART data before entering
  power-saving mode.
  Supports SMART auto save timer.
Error logging capability:  (0x01) Error logging supported.
  General Purpose Logging supported.
Short self-test routine
recommended polling time:  (  1) minutes.
Extended self-test routine
recommended polling time:  (  2) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG  VALUE WORST THRESH TYPE  UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate  0x000b  100  100  050  Pre-fail  Always  -  0
  2 Throughput_Performance  0x0005  100  100  050  Pre-fail  Offline  -  0
  3 Spin_Up_Time  0x0007  100  100  050  Pre-fail  Always  -  0
  5 Reallocated_Sector_Ct  0x0013  100  100  050  Pre-fail  Always  -  0
  7 Unknown_SSD_Attribute  0x000b  100  100  050  Pre-fail  Always  -  0
  8 Unknown_SSD_Attribute  0x0005  100  100  050  Pre-fail  Offline  -  0
  9 Power_On_Hours  0x0012  100  100  000  Old_age  Always  -  922
 10 Unknown_SSD_Attribute  0x0013  100  100  050  Pre-fail  Always  -  0
 12 Power_Cycle_Count  0x0012  100  100  000  Old_age  Always  -  26
168 Unknown_Attribute  0x0012  100  100  000  Old_age  Always  -  2
175 Program_Fail_Count_Chip 0x0003  100  100  010  Pre-fail  Always  -  0
187 Reported_Uncorrect  0x0003  100  100  010  Pre-fail  Always  -  0
192 Power-Off_Retract_Count 0x0012  100  100  000  Old_age  Always  -  3
194 Temperature_Celsius  0x0022  027  027  000  Old_age  Always  -  27
170 Unknown_Attribute  0x0003  100  100  010  Pre-fail  Always  -  64
173 Unknown_Attribute  0x0012  100  100  000  Old_age  Always  -  2359386
197 Current_Pending_Sector  0x0012  100  100  000  Old_age  Always  -  0
199 UDMA_CRC_Error_Count  0x0012  100  100  050  Old_age  Always  -  0
218 Unknown_Attribute  0x000b  100  100  050  Pre-fail  Always  -  0
233 Media_Wearout_Indicator 0x000b  100  100  000  Pre-fail  Always  -  161
240 Unknown_SSD_Attribute  0x0013  100  100  050  Pre-fail  Always  -  0
241 Total_LBAs_Written  0x0013  100  100  000  Pre-fail  Always  -  111
242 Total_LBAs_Read  0x0013  100  100  000  Pre-fail  Always  -  24
244 Unknown_Attribute  0x0002  100  100  050  Old_age  Always  -  36
245 Unknown_Attribute  0x0002  100  100  050  Old_age  Always  -  90
246 Unknown_Attribute  0x0002  100  100  050  Old_age  Always  -  308350

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


Selective Self-tests/Logging not supported

m4rkus schrieb:
Die Seriennummer bekommst du auch mit camcontrol raus.
Zum Vergrößern anklicken....
Danke. Ich habe gehofft das es so eine Möglichkeit gibt...


Grüße,
errorsmith
 
Das kann auch ein Schluckauf oder ein Staubkorn im Stecker gewesen sein. Aber willst du das testen?
 
Nicht mit einem zroot... Allerdings kann ich ssd ja woanders weiter nutzen wenn sie ja eigentlich noch in Ordnung ist.

Grüße,
Errorsmith
 
Ich würde als erstes immer die Kabel tauschen. Ich hab schon so manches defektes SATA kabel gehabt. Die scheinen nicht wirklich haltbarer zu sein, als IDE-Kabel (und das will schon was heißen).
 
Nun, ich muss den eh aufschrauben zum SSD tauschen und weil ich noch ein paar Karten dazu baue. Dann kann ich die ja auch gleich tauschen. Hab noch nen ganzen Sack hier rumliegen. Die "alte" SSD werde ich gründlich durchtesten und ggf. in einen anderen Rechner bauen.

Danke erstmal für eure Hilfe

Grüße,
errorsmith
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben