Project

General

Profile

Actions

Bug #13017

closed

Dump unique configurations and Uberblocks in zdb -lu

Added by Jason King 9 months ago. Updated 9 months 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 #1

Updated by Electric Monk 9 months ago

  • Gerrit CR set to 831
Actions #2

Updated by Jason King 9 months ago

While testing w/ the full zfs test suite, it appears the zdb changes cause problems with the zpool create create-o_ashift test. However it appears FreeBSD hit this as well:

commit 873cd182de5ff49cdad26381665d21543036a051
Author: Ryan Moeller <ryan@iXsystems.com>
Date:   Wed Feb 19 13:27:23 2020 -0500

    ZTS: Fix zpool_create/create-o_ashift on FreeBSD

    For some unknown reason, egrep was misbehaving with this pattern on
    FreeBSD.  The command works fine run interactively from a shell, but
    in the test the output of egrep is empty.

    Work around the issue by using a filter in the awk script instead.

    While here, add a bit of diagnostic output and other simplifications
    to the awk script as well.

    Reviewed-by: John Kennedy <john.kennedy@delphix.com>
    Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
    Signed-off-by: Ryan Moeller <ryan@iXsystems.com>
    Closes #10023

Including this change allows the test to complete successfully.

Actions #3

Updated by Jason King 9 months ago

Including the above fix, the only unexpected zfs test failure was the bootfs_006_pos test. However examination of that test and the test output determined that it was unrelated to this change. #13020 was filed for that issue (tl;dr #12894 missed updating some test cases in bootfs_006_pos causing it to fail).

Actions #4

Updated by Electric Monk 9 months ago

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

git commit 0caa75193db78d20398498ff9eca8f1c173ec99c

commit  0caa75193db78d20398498ff9eca8f1c173ec99c
Author: Olaf Faaland <faaland1@llnl.gov>
Date:   2020-08-06T19:49:48.000Z

    13017 Dump unique configurations and Uberblocks in zdb -lu
    Portions contributed by: Ryan Moeller <ryan@iXsystems.com>
    Portions contributed by: Jason King <jason.king@joyent.com>
    Reviewed by: Tim Chase <tim@chase2k.com>
    Reviewed by: Don Brady <don.brady@intel.com>
    Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
    Reviewed by: John Kennedy <john.kennedy@delphix.com>
    Reviewed by: Andy Fiddaman <andy@omniosce.org>
    Reviewed by: C Fraire <cfraire@me.com>
    Approved by: Richard Lowe <richlowe@richlowe.net>

Actions

Also available in: Atom PDF