-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
DLPX-57225 Reads from indirect mirrors only fin...
...d one copy Reviewed at: http://reviews.delphix.com/r/38104/ Ported-by: Tim Chase <tim@chase2k.com> Signed-off-by: Tim Chase <tim@chase2k.com> Requires-builders: none Problem 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 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 problem manifests itself in several ways: 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 scrub doesn't repair all data on the mirror (if some of it is pointed to via an indirect vdev). Solution: as an expedient fix, we will do the following: When reading a non-split block, the indirect vdev will pass the whole BP down to the mirror code. This lets the mirror code deal with verifying the checksum and trying other copies, etc. So for non-split blocks (typically >90% of all relocated blocks), the problem is completely solved. When reading split blocks, read the left side of all mirrors, and if the checksum of that fails, read the right side of all mirrors (and the 3rd side for 3-way mirrors, etc). This ensures that if there is a good copy of the data, we will return it. However, it doesn't issue repair i/os, and it doesn't fix scrub for indirect split blocks. A full fix will be the subject of a later PR. Porting notes: Commit 9f50093, "FreeBSD r256956: Improve ZFS N-way mirror read performance by using load and locality information" caused vdev_mirror.c. do diverge from the upstream code. Among other things, parts of vdev_mirror_map_alloc() were moved into the new vdev_mirror_map_init() function. The upstream version of this patch modified vdev_mirror_map_init() to select the child vdev based on the new zio hint. That code has been slightly refactored and put into vdev_mirror_map_init(). Upstream commit 20ef1b6, "8473 scrub does not detect errors on active spares" has not been ported to ZoL. It changed the name of the "mm_replacing" member of "struct mirror_map" to "mm_resilvering". The name has been left as "mm_replacing".
- Loading branch information
Showing
4 changed files
with
132 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
there's a bug here (and in the OpenZFS PR) - this should be
sizeof (*iv)
. I'll fix it there too.