Matthew Ahrens d87676a9fa
Fix i/o error handling of livelists and zap iteration
Pool-wide metadata is stored in the MOS (Meta Object Set).  This
metadata is stored in triplicate, in addition to any pool-level
reduncancy (e.g. RAIDZ).  However, if all 3+ copies of this metadata are
not available, we can still get EIO/ECKSUM when reading from the MOS.
If we encounter such an error in syncing context, we have typically
already committed to making a change that we now can't do because of the
corrupt/missing metadata.  We typically "handle" this with a `VERIFY()`
or `zfs_panic_recover()`.  This prevents the system from continuing on
in an undefined state, while minimizing the amount of error-handling
code.

However, there are some code paths that ignore these i/o errors, or
`ASSERT()` that they don't happen.  Since assertions are disabled on
non-debug builds, they effectively ignore them as well.  This can lead
to ZFS continuing on in an incorrect state, potentially leading to
on-disk inconsistencies.

This commit adds handling for these i/o errors on MOS metadata,
typically with a `VERIFY()`:

* Handle error return from `zap_cursor_retrieve()` in 4 places in
`dsl_deadlist.c`.

* Handle error return from `zap_contains()` in `dsl_dir_hold_obj()`.
Turns out this call isn't necessary because we can always call
`zap_lookup()`.

* Handle error return from `zap_lookup()` in `dsl_fs_ss_limit_check()`.

* Handle error return from `zap_remove()` in `dsl_dir_rename_sync()`.

* Handle error return from `zap_lookup()` in
`dsl_dir_remove_livelist()`.

* Handle error return from `dsl_process_sub_livelist()` in
`spa_livelist_delete_cb()`.

Additionally:

* Augment the internal history log message for `zfs destroy` to note
which method is used (e.g. bptree, livelist, or, synchronous) and the
mintxg.

* Correct a comment in `dbuf_init()`.

* Correct indentation in `dsl_dir_remove_livelist()`.

Reviewed by: Sara Hartse <sara.hartse@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #10643
2020-08-05 10:22:09 -07:00
..
2020-07-24 21:09:20 -07:00
2020-08-01 11:17:18 -07:00
2020-06-18 12:21:25 -07:00
2019-07-26 10:54:14 -07:00
2020-07-29 16:35:33 -07:00
2020-07-29 16:35:33 -07:00
2019-06-19 09:48:12 -07:00
2020-06-09 21:24:09 -07:00
2020-06-18 12:20:38 -07:00
2020-06-18 12:21:18 -07:00
2019-12-03 09:51:44 -08:00
2020-06-18 12:21:25 -07:00
2020-06-18 12:20:38 -07:00
2020-06-09 21:24:09 -07:00
2020-06-18 12:20:38 -07:00
2020-06-18 12:20:38 -07:00
2020-07-03 11:05:50 -07:00
2019-09-02 17:56:41 -07:00
2020-06-18 12:21:25 -07:00
2020-06-18 12:21:25 -07:00
2017-10-11 16:54:48 -04:00
2020-06-18 12:21:25 -07:00
2020-07-03 11:05:50 -07:00
2019-06-19 09:48:12 -07:00
2019-10-11 10:13:21 -07:00
2020-07-29 16:35:33 -07:00
2020-07-29 16:35:33 -07:00
2020-06-18 12:20:38 -07:00
2020-06-18 12:21:25 -07:00
2020-06-18 12:21:25 -07:00
2020-06-18 12:21:25 -07:00
2019-09-02 17:56:41 -07:00
2020-07-03 11:05:50 -07:00
2019-10-09 10:36:03 -07:00
2020-07-03 11:05:50 -07:00
2020-07-03 11:05:50 -07:00
2019-06-20 18:29:02 -07:00
2020-07-03 11:05:50 -07:00
2020-06-09 21:24:09 -07:00
2020-06-09 10:15:08 -07:00
2020-07-29 17:04:34 -07:00
2020-07-29 16:35:33 -07:00
2020-06-18 12:21:25 -07:00
2019-09-02 17:56:41 -07:00
2020-06-18 12:20:38 -07:00
2020-07-29 16:35:33 -07:00
2020-06-18 12:21:32 -07:00
2020-06-18 12:20:38 -07:00
2020-06-18 12:20:38 -07:00
2020-06-18 12:20:38 -07:00
2020-06-18 12:21:25 -07:00
2020-06-18 12:21:18 -07:00
2020-07-29 09:43:33 -07:00
2020-06-09 21:24:09 -07:00