Actions
Bug #13017
closedDump unique configurations and Uberblocks in zdb -lu
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
Updated by Jason King almost 2 years 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.
Updated by Jason King almost 2 years 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).
Updated by Electric Monk almost 2 years 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