ZFS Hangs After Snapshot Removal on Pool With Corruption

[Ghan04]

ZFS Hangs After Snapshot Removal on Pool With Corruption

[rincebrain]

Specifically, the error means "the offset we are trying to free is not a valid offset on this vdev" - e.g. if you had an ashift 12 (4k) vdev, and tried to free something that was 512b into it, you'd trip this.

You might be able to import the pool read-only (since it's not going to evaluate trying to free anything or free space or anything) and yank your data off that way.

[Ghan04]

I did try a read-only import but it threw the same error message and hung again. I just have the one vdev and it is 4k ashift. Would this be pointing at a single block's offset or is this something about the metadata of the entire vdev?

Edit: I've also tried

echo 1 >> /sys/module/zfs/parameters/zfs_recover

Followed by a read-only import with no luck. Same panic error.

[rincebrain]

Might be able to use git's zdb feature to emit send streams from things too damaged to import normally and get datasets off that way.

I believe it's referring to thinking it has an element to free from a metaslab and finding out the metaslab is e.g. 4k aligned and it's trying to remove 512b into it, or something like that. So it's a specific object, but it's already pending removal in its head.

You could try a readonly import at an older txg for the older txgs listed in the uberblock still, that might or might not fly. You could also use zdb to try "simulating" if that's going to panic rather than letting your kernel do it.