Handle damaged blk_birth in dsl_deadlist_insert()

[behlendorf]

If a bit were cleared in bp->blk_birth such that the txg birth
was now lower than any other txg_birth in the deadlist, then there
will be no entry before this in the tree.

This should be impossible but regardless error handling code has
been added for this case. By default this is left as a fatal case
and the blk_birth is logged. However, setting zfs_recover=1 will
cause the bp to be placed at the start of the deadlist even though
it contains an invalid blk_birth.

Signed-off-by: Brian Behlendorf behlendorf1@llnl.gov

[tuxoko]

@behlendorf
What would happen a bp belongs to other dle be put to the front?

[behlendorf]

Yes, I should have mentioned the consequences. Assuming it's just the birth txg which has been damaged then this bp may end up being considered to be part of more snapshots than it really is. In which case it won't be freed at the right time and that space may be leaked. Not good, so we don't want it to be the default. But better than a panic which many people will treat as a total pool loss.

[tuxoko]

Yeah, I think you're right. And at least it wouldn't cause the block to be removed earlier than it should.
I also think we should get more info out of the bp, like type, level. In case this is caused be some software bug.

[behlendorf]

I modeled the error message after those found in zfs_blkptr_verify() for consistency. But I completely agree that we should log more information while we can. I'd suggest adding a helper function so we could easily call this throughout the code. Probably a wrapper around zfs_panic_recover, maybe called zfs_blkptr_debug which takes a blkptr_t and a variable args error message.