Praktischerweise ist eine der beiden Festplatten im rpool eine externe USB-Festplatte. Die Platten sind gespiegelt und so wollte ich ausprobieren wie sich OpenSolaris beim Verlust einer der Platten verhält.
Wir beginnen mit einem vollständigen Mirror. Natürlich darf man das nicht ausprobieren solange die Synchronisation auf die zweite Platte noch läuft.
thomas@srvt01:~$ zpool status rpool
pool: rpool
state: ONLINE
scrub: scrub completed after 0h26m with 0 errors on Sun Jun 27 18:27:31 2010
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c10t0d0s0 ONLINE 0 0 0
c4t0d0s0 ONLINE 0 0 0
errors: No known data errors
Das sieht schon fast zu gut aus, daher trenne ich das USB-Kabel zu c4t0d0, was gleich darauf im Logfile angezeigt wird mit ‚drive offline‘.
ZFS hat das Laufwerk noch nicht völlig aufgegeben, meldet aber erste Schreib- und Lesefehler:
thomas@srvt01:~$ zpool status rpool
pool: rpool
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 0h26m with 0 errors on Sun Jun 27 18:27:31 2010
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c10t0d0s0 ONLINE 0 0 0
c4t0d0s0 ONLINE 4 5 0
errors: No known data errors
Ein wenig später sieht ZFS wohl ein, dass das Laufwerk weg ist:
thomas@srvt01:~$ zpool status rpool
pool: rpool
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'.
scrub: scrub completed after 0h26m with 0 errors on Sun Jun 27 18:27:31 2010
config:
NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c10t0d0s0 ONLINE 0 0 0
c4t0d0s0 REMOVED 0 0 0
errors: No known data errors
Noch immer steht: ‚errors: No known data errors‘. Dies ist korrekt, schliesslich sind alle Daten noch auf der verfügbaren Disk vorhanden.
Soweit so gut, also die externe Festplatte wieder anschliessen, kurz warten und den ZFS status kontrollieren:
thomas@srvt01:~$ zpool status rpool
pool: rpool
state: ONLINE
scrub: resilver completed after 0h0m with 0 errors on Sun Jun 27 19:05:42 2010
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c10t0d0s0 ONLINE 0 0 0
c4t0d0s0 ONLINE 0 0 0 3.73M resilvered
errors: No known data errors
ZFS hat das Laufwerk wieder erkannt und die inzwischen veränderten 3.73MB innert weniger Sekunden synchronisiert. Der Pool ist wieder redundant.
Perfekt, so sollte es sein. Natürlich sollte man noch weitere Tests durchführen. Ganz wichtig ist, dass auch ab der zweiten Platte gebootet werden kann. Solange ich noch keine zweite, interne System-HD habe werde ich diesen Test noch aufschieben. Was ich aber wissen will ist, ob auch der Verlust der internen SATA-Platte so gut verarbeitet werden kann. Also Gehäuse auf, SATA-Kabel raus.
Die Reaktion des Systemes ist leich anders, so finde ich diese Zeile im Logfile:
fmd: [ID 377184 daemon.error] SUNW-MSG-ID: ZFS-8000-HC, TYPE: Error, VER: 1, SEVERITY: Major
und ZFS meldet die Festplatte nicht als ‚REMOVED‘ sondern als ‚UNAVAILABLE‘.
thomas@srvt01:~$ zpool status rpool
pool: rpool
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scrub: resilver completed after 0h0m with 0 errors on Sun Jun 27 19:05:42 2010
config:
NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c10t0d0s0 UNAVAIL 4 784 0 experienced I/O failures
c4t0d0s0 ONLINE 0 0 0 3.73M resilvered
errors: No known data errors
Trotzdem läuft das System weiter, die externe USB-HD erfüllt den Dienst. Da es mir mit dieser alten externen HD nicht so wohl ist verbinde ich das SATA-Kabel erneut.
Auch hier reagiert das System anders. ZFS bindet die Platte nicht automatisch neu ein sondern meldet die Platte nun als ‚REMOVED‘:
thomas@srvt01:~$ zpool status rpool
pool: rpool
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'.
scrub: resilver completed after 0h0m with 0 errors on Sun Jun 27 19:05:42 2010
config:
NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c10t0d0s0 REMOVED 0 0 0
c4t0d0s0 ONLINE 0 0 0 3.73M resilvered
errors: No known data errors
Wie in der Status-Ausgabe empfohlen versuche ich die Disk mit ‚zpool online‘ wieder zu aktivieren, was aber nicht klappen will.
thomas@srvt01:~$ pfexec zpool online rpool c10t0d0s0 warning: device 'c10t0d0s0' onlined, but remains in faulted state use 'zpool replace' to replace devices that are no longer present
Die Ausgabe von ‚zpool status rpool‘ bestätigt meine Befürchtung, der Status der Disk ist noch immer ‚REMOVED‘. Auch ‚format‘ zeigt diese Disk nicht mehr an. HILFE!
Kurz in Google nachgeschaut finde ich einen Hinweis auf den ‚cfgadm‘ Befehl. Dazu muss erst die ID des Gerätes bekannt sein. ‚cfgadm -lav‘ zeigt eine lange Liste (gekürzt):
thomas@srvt01:~$ cfgadm -lav Ap_Id Receptacle Occupant Condition sata0/0 connected unconfigured unknown Mo.. sata0/1 empty unconfigured ok sata0/2::dsk/c10t2d0 connected configured ok Mo.. sata0/3::dsk/c10t3d0 connected configured ok Mo.. sata0/4::dsk/c10t4d0 connected configured ok Mo..
Auffällig ist hier der Status der ersten Festplatte, markiert mit ’sata0/0′: ‚connected unconfigured‘. Also das System zum Konfigurieren dieser Platte überreden mit ‚pfexec cfgadm -c configure sata0/0‘. Exakt in dem Moment beginnt die externe HD zu rattern, der Pool sieht wieder gut aus und mein Puls sinkt:
thomas@srvt01:~$ zpool status rpool
pool: rpool
state: ONLINE
scrub: scrub in progress for 0h6m, 22.90% done, 0h20m to go
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c10t0d0s0 ONLINE 0 0 0
c4t0d0s0 ONLINE 0 0 0
errors: No known data errors
Offensichtlich hat OpenSolaris beschlossen, dass ein Scrubbing des Pools nötig ist. Nicht die schlechteste Idee nach diesem Ereignis.
Eine Disk kann also verschwinden, ohne dass ich etwas merke. Dies sollte unbedingt später mit einer Monitoring-Software überwacht werden. Über das OpenSolaris Fault Management System sollte es möglich sein solche Informationen zu kriegen.