Letzte Woche hielt mein Server eine Hiobsbotschaft für mich bereit:
+ahcich0: Timeout on slot 23 port 0 +ahcich0: is 00000000 cs 01800000 ss 00000000 rs 01800000 tfd c0 serr 00000000 cmd 0000f717 +ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080) +ahcich0: Timeout on slot 24 port 0 +ahcich0: is 00000000 cs 01000000 ss 00000000 rs 01000000 tfd 80 serr 00000000 cmd 0000f817 +ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080) +ahcich0: Timeout on slot 24 port 0 +ahcich0: is 00000000 cs 01000000 ss 00000000 rs 01000000 tfd 80 serr 00000000 cmd 0000f817 +(ada0:ahcich0:0:0:0): lost device +ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080) +ahcich0: Timeout on slot 24 port 0 +ahcich0: is 00000000 cs 03000000 ss 00000000 rs 03000000 tfd 80 serr 00000000 cmd 0000f817 +(ada0:ahcich0:0:0:0): removing device entry +ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080) +ahcich0: Poll timeout on slot 25 port 0 +ahcich0: is 00000000 cs 02000000 ss 00000000 rs 02000000 tfd 80 serr 00000000 cmd 0000f917
Festplattenausfall! Die betroffene Platte war Teil eines ZFS-Raids aus vier Platten. Entsprechend sah auch die ZFS-Statusmeldung aus:
Checking status of zfs pools: NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT pool 7.25T 5.22T 2.03T 72% 1.00x DEGRADED - pool: pool state: DEGRADED status: One or more devices has been removed by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scan: none requested config: NAME STATE READ WRITE CKSUM pool DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 13091973070404888760 REMOVED 0 0 0 was /dev/ada0p1 ada1p1 ONLINE 0 0 0 ada2p1 ONLINE 0 0 0 ada3p1 ONLINE 0 0 0 errors: No known data errors
Die gute Nachricht an dieser Stelle: Der Pool ist im Status DEGRADED und nicht FAULTED. Also standen die Chancen für eine Wiederherstellung gut. Am Wochenende habe ich nun also eine neue Festplatte gekauft und zunächst mit Hilfe eines externen Gehäuses angeschlossen. Grund für diesen Zwischenschritt: Ich habe dem ZFS-Raid nicht die gesamten Platten zur Verfügung gestellt, sondern lediglich Partitionen auf den Platten. Damit umgeht man das Problem der unterschiedlichen Sektorenanzahl, falls man doch mal Festplatten unterschiedlicher Baureihen oder Hersteller nutzt. Einzige Voraussetzung für die Partition auf einer neuen Festplatte: Sie muss mindestens genauso groß sein, wie die Partition auf der auszutauschenden Platte.
Also ans Werk. Zunächst prüfen wir, ob die neue Platte bereits formatiert ist. Da dies nicht der Fall ist, legen wir zunächst ein GPT-Partitionsschema an:
> gpart show da0
gpart: No such geom: da0.
> gpart create -s gpt /dev/da0
da0 created
Um nun herauszufinden, wie groß die Partition sein muss, sehen wir uns eine der anderen Platten im Raid genauer an, da sie alle mit identischem Partitionsschema und gleicher Partitionsgröße formatiert sind:
> gpart show /dev/ada1
=> 34 3907029101 ada1 GPT (1.8T)
34 2014 - free - (1M)
2048 3907027080 1 freebsd-zfs (1.8T)
3907029128 7 - free - (3.5k)
Da es sich bei allen eingesetzten Platten um Platten mit 4K großen Sektoren handelt, müssen wir auf das korrekte Alignment achten. gpart auf FreeBSD bietet hierfür den Parameter -a an. Zur Sicherheit lassen wir die Partition explizit an der 1-MB-Grenze starten (Parameter -b). Anschließend prüfen wir das Partitionsschema.
> gpart add -a 4k -b 2048 -t freebsd-zfs /dev/da0
da0p1 added
> gpart show /dev/da0
=> 34 3907029101 da0 GPT (1.8T)
34 2014 - free - (1M)
2048 3907027080 1 freebsd-zfs (1.8T)
3907029128 7 - free - (3.5k)
Die Partition auf der neuen Platte hat genau die gleiche Größe, wie unsere Vergleichsplatte. Nun kann die defekte Festplatte ausgetauscht werden. Hierzu musste ich den Server herunterfahren und mich zunächst durch eine zentimeterdicke Staubschicht arbeiten. Idealer Zeitpunkt für einen Frühjahrsputz! 🙂
Nach dem Hochfahren des Rechners kann nun die Partition auf der neuen Festplatte dem ZFS-Raid zur Verfügung gestellt werden. Wichtig ist hier, dass der Name der alten Partition verwendet wird und nicht die angegebene ID. Der neue Name kann weggelassen werden, da die alte und die neue Partition den gleichen dev-Namen haben (hier: ada0p1).
> zpool replace pool ada0p1
Wenn man nun den Status des ZFS-Raids abfragt, wird man feststellen, dass der Resilver-Prozess sofort nach Einbinden der neuen Partition losläuft:
> zpool status
pool: pool
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sat Apr 18 20:03:31 2015
26,6G scanned out of 5,39T at 102M/s, 15h19m to go
6,65G resilvered, 0,48% done
config:
NAME STATE READ WRITE CKSUM
pool DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
replacing-0 REMOVED 0 0 0
13091973070404888760 REMOVED 0 0 0 was /dev/ada0p1/old
ada0p1 ONLINE 0 0 0 (resilvering)
ada1p1 ONLINE 0 0 0
ada2p1 ONLINE 0 0 0
ada3p1 ONLINE 0 0 0
errors: No known data errors
Die ganze Operation wurde in meinem Fall nach ca. zwölf Stunden erfolgreich abgeschlossen:
> zpool status
pool: pool
state: ONLINE
scan: resilvered 1,35T in 12h7m with 0 errors on Sun Apr 19 08:11:21 2015
config:
NAME STATE READ WRITE CKSUM
pool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ada0p1 ONLINE 0 0 0
ada1p1 ONLINE 0 0 0
ada2p1 ONLINE 0 0 0
ada3p1 ONLINE 0 0 0
errors: No known data errors
Alles wieder gut und mit ruhigem Gewissen sehe ich dem nächsten Festplattenausfall entgegen…
Das war übrigens WD Green 2 TB Numero eins von vier. Ersetzt habe ich sie durch eine WD Red 2 TB.