diff --git a/FAQ.md b/FAQ.md index fef1b91..d7d9030 100644 --- a/FAQ.md +++ b/FAQ.md @@ -206,9 +206,9 @@ $ zpool set cachefile=none tank ### hole_birth Bugs -The hole_birth feature has/had bugs, the result of which is that, if you do a zfs send -i (or -R, since it uses -i) from an affected dataset, the receiver *will not see any checksum or other errors, but will not match the source*. +The hole_birth feature has/had bugs, the result of which is that, if you do a `zfs send -i` (or `-R`, since it uses `-i`) from an affected dataset, the receiver *will not see any checksum or other errors, but will not match the source*. -0.6.5.8 and 0.7.0-rc1 (and above) default to ignoring the faulty metadata which causes this issue *on the sender side*. +ZoL versions 0.6.5.8 and 0.7.0-rc1 (and above) default to ignoring the faulty metadata which causes this issue *on the sender side*. For more details, see the [[hole_birth FAQ]]. diff --git a/hole_birth-FAQ.md b/hole_birth-FAQ.md index d64ace3..a846547 100644 --- a/hole_birth-FAQ.md +++ b/hole_birth-FAQ.md @@ -1,15 +1,15 @@ ### Short explanation -The hole_birth feature has/had bugs, the result of which is that, if you do a zfs send -i (or -R, since it uses -i) from an affected dataset, the receiver *will not see any checksum or other errors, but will not match the source*. +The hole_birth feature has/had bugs, the result of which is that, if you do a `zfs send -i` (or `-R`, since it uses `-i`) from an affected dataset, the receiver *will not see any checksum or other errors, but will not match the source*. -0.6.5.8 and 0.7.0-rc1 (and above) default to ignoring the faulty metadata which causes this issue *on the sender side*. +ZoL versions 0.6.5.8 and 0.7.0-rc1 (and above) default to ignoring the faulty metadata which causes this issue *on the sender side*. ### FAQ -#### I have a pool with hole_birth enabled, how do I know if I'm affected? -It's technically possible to calculate whether you have any affected files, but it requires scraping zdb output for each file in each snapshot in each dataset, which is a combinatoric nightmare. (If you really want it, there's a proof of concept [here](https://github.com/rincebrain/hole_birth_test) +#### I have a pool with hole_birth enabled, how do I know if I am affected? +It is technically possible to calculate whether you have any affected files, but it requires scraping zdb output for each file in each snapshot in each dataset, which is a combinatoric nightmare. (If you really want it, there is a proof of concept [here](https://github.com/rincebrain/hole_birth_test). -#### Is there any less painful way to fix this if we've already received an affected snapshot? -No, the data you need was simply not present in the send stream, unfortunately, and can't feasibly be rewritten in place. +#### Is there any less painful way to fix this if we have already received an affected snapshot? +No, the data you need was simply not present in the send stream, unfortunately, and cannot feasibly be rewritten in place. ### Long explanation hole_birth is a feature to speed up ZFS send -i - in particular, ZFS used to not store metadata on when "holes" (sparse regions) in files were created, so every zfs send -i needed to include every hole. @@ -18,8 +18,8 @@ hole_birth, as the name implies, added tracking for the txg (transaction group) Unfortunately, hole_birth had a number of edge cases where it could "forget" to set the birth_time of holes in some cases, causing it to record the birth_time as 0 (the value used prior to hole_birth, and essentially equivalent to "since file creation"). -This meant that, when you did a zfs send -i, since zfs send doesn't have any knowledge of the surrounding snapshots when sending a given snapshot, it would see the creation txg as 0, conclude "oh, it's 0, I must have already sent this before", and not include it. +This meant that, when you did a zfs send -i, since zfs send does not have any knowledge of the surrounding snapshots when sending a given snapshot, it would see the creation txg as 0, conclude "oh, it is 0, I must have already sent this before", and not include it. -This means that, on the receiving side, it doesn't know those holes should exist, and doesn't create them - leading to differences between what you have on the source and the destination. +This means that, on the receiving side, it does not know those holes should exist, and does not create them. This leads to differences between the source and the destination. -0.6.5.8 and 0.7.0-rc1 (and above) default to ignoring this metadata and always sending holes with birth_time 0, configurable using the tunable known as "ignore_hole_birth" or "send_holes_without_birth_time" (the latter is what OpenZFS standardized on; 0.6.5.8 only has the former, but for any ZoL version with send_holes_without_birth_time, they point to the same value, so changing either will work). +ZoL versions 0.6.5.8 and 0.7.0-rc1 (and above) default to ignoring this metadata and always sending holes with birth_time 0, configurable using the tunable known as `ignore_hole_birth` or `send_holes_without_birth_time`. The latter is what OpenZFS standardized on. ZoL version 0.6.5.8 only has the former, but for any ZoL version with `send_holes_without_birth_time`, they point to the same value, so changing either will work.