I85PREP
⌘ K
LPI BSD Specialist study materials
LPI BSD Specialist study resources

Replacing a Failing Disk in a Full RAIDZ1 ZFS Pool

LPI BSD Specialist · Put your knowledge to work in context.

All case studies

Replacing a Failing Disk in a Full RAIDZ1 ZFS Pool

A FreeBSD 14.0 file server exports a ZFS pool named tank built from four 4 TB SATA disks in a single raidz1 vdev. The boot disk is a separate SSD. zpool status shows ada3 ONLINE but with 18 reallocated sectors and a growing read-error count; smartctl reports a failing attribute. The pool is 84% full and holds hourly snapshots retained for seven days. The server serves NFS clients during business hours, and management has approved only a 30-minute maintenance window, although the failed disk can be swapped while the system runs. There is no hot spare and no empty drive bay, so the replacement disk must go into the slot currently occupied by ada3. The administrator wants to know whether to replace the disk now, add a new vdev, or wait until the next quarter.

1. Assess the urgency and give the replacement procedure, including commands and the expected downtime.

Read the worked answer

Replace the disk now. A raidz1 vdev has single-disk redundancy; with one disk already showing errors, a second failure would lose the pool. Waiting a quarter is not a defensible risk decision for data that is still readable.

Procedure:

  1. Record the exact vdev path with zpool status -v tank. Confirm whether the vdev is a whole disk such as ada3 or a GPT partition or label such as gpt/disk3.
  2. Run smartctl -a /dev/ada3 and save the output for the hardware ticket.
  3. Take the disk offline: zpool offline tank ada3.
  4. Swap the physical disk. If the original vdev was a GPT partition, recreate the same scheme with gpart create -s gpt ada3 and gpart add -t freebsd-zfs ada3; if it was a whole-disk vdev, do not partition it.
  5. Start replacement with zpool replace tank ada3 if the new disk has the same path, or zpool replace tank ada3 /dev/ada4 if it has a different path.
  6. Watch zpool status -v until resilvering completes. Do not start a scrub during the resilver.

The 30-minute window is probably too short to finish resilvering, but the pool remains available while it runs. The disk swap itself can be quick; the resilver continues online, so no full outage is required.

2. The pool is 84% full. Should the administrator add one more disk to expand capacity? Explain the ZFS consequences.

Read the worked answer

Adding a single disk with zpool add tank ada4 would create a new single-disk vdev, not expand the existing raidz1. That new vdev has no redundancy, and if it fails the entire pool can be lost. It also changes the failure domain and may not distribute data the way the administrator expects. This is a poor choice for a pool that already has a failing disk.

Better options are to reduce space consumption first: delete expired snapshots, check for deleted-but-open files, and set compression such as zfs set compression=lz4 tank/data where appropriate. If more capacity is truly needed, add a redundant vdev, such as a mirrored pair or another raidz vdev, and ensure there are enough bays. If no bays exist, migrate to a larger chassis or larger disks rather than adding an unprotected stripe.

At 84% full, performance and fragmentation are also concerns. ZFS likes free space, so relieving pressure before a resilver is sensible. Do not attach a disk to a raidz1 vdev as though it were a mirror; that is not how raidz redundancy works.

3. What monitoring and preventive steps would you put in place after the replacement?

Read the worked answer

Enable SMART monitoring and make sure alerts reach someone. Install and configure smartd for the data disks, and keep zpool status -v in a daily check. A simple periodic script can run zpool status -x and zpool list -H -o capacity and mail the output; the important part is that a degraded or capacity-threshold event is acted on.

Schedule a scrub at a low-usage time, typically monthly, but do not run it during a resilver. Keep the snapshot policy under review so that hourly snapshots do not silently consume the pool. Use zpool history when investigating changes. Replace disks proactively when SMART attributes degrade, and maintain at least one spare disk or an agreed procurement path so the next replacement does not wait on purchasing.