ZFS – Dealing with Failed Drives, using spares and new drives – and autoreplace




Spares usually auto fall a failed drive (this is not to be confused with autoreplace feature, which as you will see in a little bit, just replaces a bad drive with another drive it detects in its place).

The automatic process defined by Oracle blogger “eschrock” (see link above) happens automatically like so:

“There is now an FMA agent, zfs-retire, which subscribes to vdev failure faults and automatically initiates replacements if there are any hot spares available.”

To manually do it:

The process for Spares to fall in place of a bad drive should be automatic, and depend on the fmd ZFS agent, which by default works.

NOTE: Drives <disk> have numerous different ways of appearing, here are some variations (from zdb output):
guid: 3116999365654966099
path: ‘/dev/dsk/c0t5000C5004EF4D025d0s0’ (s0 thats a slice/partition, which elapses full drive)
devid: ‘id1,sd@n5000c5004ef4d025/a’
phys_path: ‘/scsi_vhci/disk@g5000c5004ef4d025:a’
Also depending on your distro the path could be different like the simple: /dev/dsk/c2t4d0
Note when refering to a drive by path, you can ommit the /dev/dsk part and just say:
c0t5000C5004EF4D025d0 (notice I remove the s0)


When you add the new drive (either turn off the system, or hot add), here are the zfs commands (I dont know about commands for such things as disk discovery):

The steps should be similar to this (from: http://docs.oracle.com/cd/E19253-01/819-5461/gbcet/)

Before you take out bad drive:

it might be advisable to do this step now:

Now lets find out the Sata name of the <old bad drive>

I will call <old bad drive> as simply <disk> here.

Example of what <sata> could say is: sata1/3

Press Y at the prompt to unconfigure the drive from its driver.

Confirm disk shows as unconfigured

Now replace the bad drive with the good drive physically on the unit (you can do it cold, unit is off, or hot, I recommend doing it hot, unit is on)

Notice that <disk> is the same name as old bad drive. Now in some cases, if your disk names are more unique and perhaps use a hash of the GUID or SERIAL NUMBER. Or perhaps its just the GUID that your using for your disk names, then instead this name should be new.



The Autoreplace feature is supposed to automate this whole procedure (maybe even the unconfiguring and configuring seen above):

zpool autoreplace (Off by default) as defined by Oracle:
“Controls automatic device replacement. If set to off, device replacement must be initiated by using the zpool replace command. If set to on, any new device found in the same physical location as a device that previously belonged to the pool is automatically formatted and replaced. The property abbreviation is replace.”

So it only replaces drives with new drives in same physical location – not with spares. Spares automatically fall in to place of a dead drive, weather autoreplace is on or off.

Of course for this feature to work best, its probably best to set this on before any occurance of problems (not tested but if you turn this on during failure, you probably still have to do the manual commands)

To turn on autoreplace:

To turn off autoreplace:

To get current setting of autoreplace:

Another way to get current autoreplace status:


Do this next step if you still see the old bad drive:

Continue here after:

After this is done the spare should go back to being a spare but if it doesnt:

Repeat last command for any other pools the <spare> was a spare for.


You can use the GUID of the drive inplace of the drive name, to get all GUIDS:

You will see a similar output to zpool status, except with alot more info in place of each line.


To go over the data with a fine tooth comb and pick out any errors, and fix the obvious ones (checksum is wrong, but the other parities say it should be this, thus it can calculate what needs to go in place of data to fix check sum):

A scrub as defined by Oracle (see link above):

“This operation traverses all the data in the pool once and verifies that all blocks can be read. Scrubbing proceeds as fast as the devices allow, though the priority of any I/O remains below that of normal operations. This operation might negatively impact performance, though the file system should remain usable and nearly as responsive while the scrubbing occurs. “

To stop a scrub:

More from oracle:

“During a scrub performance may take a hit.

In most cases, a scrub operation, to ensure data integrity, should continue to completion. Stop a scrub at your own discretion if system performance is impacted by a scrub operation.

Performing routine scrubbing also guarantees continuous I/O to all disks on the system. Routine scrubbing has the side effect of preventing power management from placing idle disks in low-power mode. If the system is generally performing I/O all the time, or if power consumption is not a concern, then this issue can safely be ignored.”

To see all of your zfs/zpool commands


Leave a Reply

Your email address will not be published. Required fields are marked *