jacobpascual/openzfs-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial wiki md to rst auto convertation

Browse Source
This commit is contained in:
George Melikov
2020-05-16 16:39:45 +03:00
commit c47d449832
57 changed files with 18232 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
docs/hole_birth-FAQ.rst Normal file
View File

@@ -0,0 +1,62 @@
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 the
resulting destination snapshot will not match the source.
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 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 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.
hole_birth, as the name implies, added tracking for the txg (transaction
group) when a hole was created, so that zfs send -i could only send
holes that had a birth_time between (starting snapshot txg) and (ending
snapshot txg), and life was wonderful.
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 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 does not know those holes
should exist, and does not create them. This leads to differences
between the source and the destination.
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.