Project

General

Profile

Actions

Bug #13017

closed

Dump unique configurations and Uberblocks in zdb -lu

Added by Jason King almost 2 years ago. Updated almost 2 years ago.

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

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

Port of OpenZFS #5738:

    From 3c9e0d673e1d47622e6be0bdb06d53fa8655cdf3 Mon Sep 17 00:00:00 2001
    From: Olaf Faaland <faaland1@llnl.gov>
    Date: Mon, 6 Mar 2017 16:01:45 -0800
    Subject: [PATCH] Dump unique configurations and Uberblocks in zdb -lu

    For zdb -l, detect when the configuration nvlist in some label l (l>0)
    is the same as a configuration already dumped.  If so, do not dump it.

    Make a similar check when dumping Uberblocks for zdb -lu.  Check whether
    a label already dumped contains an identical Uberblock.  If so, do not
    dump the Uberblock.

    When dumping a configuration or Uberblock, state which labels it is
    found in (0-3), for example: labels = 1 2 3

    Detecting redundant uberblocks or configurations is accomplished by
    calculating checksums of the uberblocks and the packed nvlists
    containing the configuration.

    If there is nothing unique to be dumped for a label (ie the
    configuration and uberblocks have checksums matching those already
    dumped) print nothing for that label.

    With additional l's or u's, increase verbosity as follows:

    -l      Dump each unique configuration only once.
            Indicate which labels it appears in.
    -ll     In addition, dump label space usage stats.
    -lll    Dump every configuration, unique or not.

    -u      Dump each unique, valid, uberblock only once.
            Indicate which labels it appears in.
    -uu     In addition, state which slots are invalid.
    -uuu    Dump every uberblock, unique or not.
    -uuuu   Dump the uberblock blockpointer (used to be -uuu)

    Make exit values conform to the manual page.  Failing to unpack a
    configuration nvlist is considered an error, as well as failing to open
    or read from the device.

    Add three tests, zdb_00{3,4,5}_pos to verify the above functionality.

    An example of the output:
            ------------------------------------
            LABEL 0
            ------------------------------------
                version: 5000
                name: 'pool'
                state: 1
                txg: 880
                < ... redacted ... >
                features_for_read:
                    com.delphix:hole_birth
                    com.delphix:embedded_data
                labels = 0
                Uberblock[0]
                    magic = 0000000000bab10c
                    version = 5000
                    txg = 0
                    guid_sum = 3038694082047428541
                    timestamp = 1487715500 UTC = Tue Feb 21 14:18:20 2017
                    labels = 0 1 2 3
                Uberblock[4]
                    magic = 0000000000bab10c
                    version = 5000
                    txg = 772
                    guid_sum = 9045970794941528051
                    timestamp = 1487727291 UTC = Tue Feb 21 17:34:51 2017
                    labels = 0
                < ... redacted ... >
            ------------------------------------
            LABEL 1
            ------------------------------------
                version: 5000
                name: 'pool'
                state: 1
                txg: 14
                < ... redacted ... >
                    com.delphix:embedded_data
                labels = 1 2 3
                Uberblock[4]
                    magic = 0000000000bab10c
                    version = 5000
                    txg = 4
                    guid_sum = 7793930272573252584
                    timestamp = 1487727521 UTC = Tue Feb 21 17:38:41 2017
                    labels = 1 2 3
                < ... redacted ... >

    Reviewed-by: Tim Chase <tim@chase2k.com>
    Reviewed-by: Don Brady <don.brady@intel.com>
    Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
    Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
    Closes #5738
Actions

Also available in: Atom PDF