ZFS Replacement of intermediate snapshots
Over the past months I proposed some ideas in the zfs-discuss list , which received some praise and some constructive criticism. I'd like to summarize here to gain attention of those developers who would like to explore this path and/or check the mark when "it is done" :)
I had an unrecoverable on-disk corruption in one block of my raidz2 pool, rendering invalid one of the "early" snapshots in a large dataset replicated from another system. With the current ZFS-Send architecture, the only method of proper recovery that I know of is to destroy this snapshot and its descendants on the corrupted pool and re-send and re-receive them from the source. (Alternatively, I can resort to ZDB to find the DVAs of corrupted data, somehow translate that into physical LBAs and replace sectors on disk from the known-good copy, so that they match the blkptr_t's checksum again).
This proposed feature calls for a method to allow replacement of only an intermediate snapshot (which references such corrupted block) without the requirement to destroy and re-receive all later snapshots. Such a feature could be used both ways, allowing recovery of either the original or the backup snapshot from the other copy.
In particular, if the feature #2019 (injection of checkpoints) is implemented, such checkpoints could be used to "fence off" the blocks (range of TXG numbers) which contain the corrupted and valid data on both sides, and replicate only this small "patch" to fix the invalid side.
I hope that such block reallocation is not much different from autorepairs on resilver or scrub which would happen if there was enough redundancy to recover from the error in the first place...
Links: discussion threads
 http://firstname.lastname@example.org/msg48110.html - newer proposal about injection of snapshots "Injection of ZFS snapshots into existing data, and replacement of older snapshots with zfs recv without truncating newer ones"
 http://email@example.com/msg48120.html - some usecases to support the proposal
No data to display