[zfs-discuss] Correct/best procedure to replace a dying (but still working) disk ?

Chris Siebenmann cks at cs.toronto.edu
Fri Aug 16 18:05:46 EDT 2013

| Detaching a defective drive seems not to work. You need to replace.
| *[root at seymour tmp]# zpool detach test /raid/tmp/d5**
| **cannot detach /raid/tmp/d5: only applicable to mirror and replacing vdevs*
| Why not detach a defective raidz drive?

 My understanding of this is that you must always have *something* in
that raidz drive slot, even if it's a failed drive (because ultimately
you can't shrink raidz vdevs). I believe this is generic ZFS behavior
not specific to ZoL. You can detach the drive once it's been spared
out because then you aren't shrinking the vdev.

 This is ultimately an implementation choice in how you represent a dead
slot. Presumably either the ZFS developers felt it was more logical this
way or it made their lives easier.

| Next one is also a bit unexpected: Using replace with a spare in place, 
| the replacement drive becomes online, aparently was resilvered, but pool 
| still shows DEGRADED ?

 I believe that this is standard ZFS behavior (including the pool
becoming non-DEGRADED when you remove the failed drive). I assume it's
to clearly mark pools that have had a spare kick in as having some sort
of a problem.

| When detaching the defective drive, it appears it resilvers again.

 I don't think it resilvered again; it's just that the resilver status
report is persistent. Your before-and-after 'scan:' reports are:

| scan: resilvered 55.5K in 0h0m with 0 errors on Fri Aug 16 13:15:08 2013
| scan: resilvered 55.5K in 0h0m with 0 errors on Fri Aug 16 13:15:08 2013

 That's the same count and end time, so I don't think it did it again.

 'scan:' output basically sticks on the last scrub or resilver that the
pool did until you export the pool or reboot the server (the information
is only held in server memory, not written to the pool[*]).

	- cks
[*: okay, this is the old Solaris behavior. Modern ZFSs may persist the
    scrub and resilver information to the pool.

To unsubscribe from this group and stop receiving emails from it, send an email to zfs-discuss+unsubscribe at zfsonlinux.org.

More information about the zfs-discuss mailing list