Project

General

Profile

Feature #2009

ZPOOL STATUS improvements for error-location (with greater verbosity)

Added by Jim Klimov over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2012-01-21
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

Currently when a "zpool scrub" locates an error, it tells us that a certain file number or path was broken - contains data which does not match its checksum, and could not be recovered by redundancy.

In order to aid data recovery (extracting and replacing certain blocks) from large external backups (instead of overwriting the whole huge file) and/or aid manual sanity checks by zfs developers and curious admins, I propose to add verbosity options for "zpool status" to report:
1) Block number and/or byte offset of the error;
2) Addressing ready for copy-paste to ZDB command lines (pool name, dataset name, object number for ZDB -DDDDD...), including physical block size and compression flags (for ZDB -R)
3) Report the DVAs of the problematic block (and its copies i.e. via mirroring) and the blkptr_t (tree?) pointing to it; and whether it was deduped (and DDT entry) - it is possible that one found error actually influences many files via dedup, clones, snapshots, etc.
4) Report the checksums caclulated from all mirror/ditto copies or raidz permutations of the block, and stored in its parent block pointer (i.e. to visually estimate the possibility of a bit flip in the stored checksum)

Also available in: Atom PDF