Link to hole_birth FAQ from FAQ

Richard Laager 2016-12-13 17:26:08 -06:00
parent e54455aab3
commit 9aaa1e71f3
2 changed files with 10 additions and 2 deletions

10
FAQ.md

@ -204,6 +204,14 @@ Conversely the cache file can be disabled by setting `cachefile=none`. This is
$ 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*.
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]].
### Performance Considerations
To achieve good performance with your pool there are some easy best practices you should follow. Additionally, it should be made clear that the ZFS on Linux implementation has not yet been optimized for performance. As the project matures we can expect performance to improve.
@ -307,4 +315,4 @@ When a new issue is opened it's not uncommon for a developer to request addition
[conservancy]: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
[fsf]: https://www.fsf.org/licensing/zfs-and-linux
[networkworld]: http://www.networkworld.com/news/2006/120606-closed-modules1.html
[issues]: https://github.com/zfsonlinux/zfs/issues
[issues]: https://github.com/zfsonlinux/zfs/issues

@ -1,5 +1,5 @@
### Short explanation
hole_birth 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*.