From 9aaa1e71f3194dbc687b0fa6557990821363ed14 Mon Sep 17 00:00:00 2001 From: Richard Laager Date: Tue, 13 Dec 2016 17:26:08 -0600 Subject: [PATCH] Link to hole_birth FAQ from FAQ --- FAQ.md | 10 +++++++++- hole_birth-FAQ.md | 2 +- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/FAQ.md b/FAQ.md index 1054167..fef1b91 100644 --- a/FAQ.md +++ b/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 \ No newline at end of file +[issues]: https://github.com/zfsonlinux/zfs/issues diff --git a/hole_birth-FAQ.md b/hole_birth-FAQ.md index cb4995e..d64ace3 100644 --- a/hole_birth-FAQ.md +++ b/hole_birth-FAQ.md @@ -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*.