Project

General

Profile

Bug #9290

device removal reduces redundancy of mirrors

Added by Matthew Ahrens over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
zfs - Zettabyte File System
Start date:
2018-03-16
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Mirrors are supposed to provide redundancy in the face of whole-disk failure and silent damage (e.g. some data on disk is not right, but ZFS hasn't detected the whole device as being broken). However, the current device removal implementation bypasses some of the mirror's redundancy. Note that in no case is incorrect data returned, but we might get a checksum error when we should have been able to find the right data.

There are two underlying problems:

1. When we remove a mirror device, we only read one side of the mirror. Since we can't verify the checksum, this side may be silently bad, but the good data is on the other side of the mirror (which we didn't read). This can cause the removal to "bake in" the busted data – all copies of the data in the new location are the same, busted version, while we left the good version behind.

The fix for this is to read and copy both sides of the mirror. If the old and new vdevs are mirrors, we will read both sides of the old mirror, and write each copy to the corresponding side of the new mirror. (If the old and new vdevs have a different number of children, we will do this as best as possible.) Even though we aren't verifying checksums, this ensures that as long as there's a good copy of the data, we'll have a good copy after the removal, even if there's silent damage to one side of the mirror. If we're removing a mirror that has some silent damage, we'll have exactly the same damage in the new location (assuming that the new location is also a mirror).

2. When we read from an indirect vdev that points to a mirror vdev, we only consider one copy of the data. This can lead to reduced effective redundancy, because we might read a bad copy of the data from one side of the mirror, and not retry the other, good side of the mirror.

Note that the problem is not with the removal process, but rather after the removal has completed (having copied correct data to both sides of the mirror), if one side of the new mirror is silently damaged, we encounter the problem when reading the relocated data via the indirect vdev. Also note that the problem doesn't occur when ZFS knows that one side of the mirror is bad, e.g. when a disk entirely fails or is offlined.

The impact is that reads (from indirect vdevs that point to mirrors) may return a checksum error even though the good data exists on one side of the mirror, and scrub doesn't repair all data on the mirror (if some of it is pointed to via an indirect vdev).

The fix for this is complicated by "split blocks" - one logical block may be split into two (or more) pieces with each piece moved to a different new location. In this case we need to read all versions of each split (one from each side of the mirror), and figure out which combination of versions results in the correct checksum, and then repair the incorrect versions.

This ensures that we supply the same redundancy whether you use device removal or not. For example, if a mirror has small silent errors on all of its children, we can still reconstruct the correct data, as long as those errors are at sufficiently-separated offsets (specifically, separated by the largest block size - default of 128KB, but up to 16MB).

History

#1

Updated by Electric Monk over 1 year ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

git commit 3a4b1be953ee5601bab748afa07c26ed4996cde6

commit  3a4b1be953ee5601bab748afa07c26ed4996cde6
Author: Matthew Ahrens <mahrens@delphix.com>
Date:   2018-04-16T20:43:30.000Z

    9290 device removal reduces redundancy of mirrors
    Reviewed by: George Wilson <george.wilson@delphix.com>
    Reviewed by: Prashanth Sreenivasa <pks@delphix.com>
    Reviewed by: Sara Hartse <sara.hartse@delphix.com>
    Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com>
    Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
    Reviewed by: Tim Chase <tim@chase2k.com>
    Approved by: Richard Lowe <richlowe@richlowe.net>

Also available in: Atom PDF