[Pkg-zfsonlinux-devel] Bug#830824: Bug#830824: Silently corrupted file in snapshots after send/receive

[Richard Laager]

I'm an Ubuntu user, and I'm not sure if Colin Ian King follows this
mailing list. I've CC'ed him. Colin, I hope you don't mind.

On 08/11/2016 10:51 AM, Carlos Alberto Lopez Perez wrote:
> On 09/08/16 16:35, Petter Reinholdtsen wrote:
>> [ Antonio Russo 2016-07-11 ]
>>> Sorry, there is no 0.6.5.8 release. The fix does exist in the master branch,
>>> however.  (bc77ba7: OpenZFS 6513 - partially filled holes lose birth time)
>>
>> As far as I can see from <URL: https://github.com/zfsonlinux/zfs/issues/4809 >,
>> the issue is still unsolved upstream.
>>
>> Are you sure that commit is enough to solve the problem?  There are others
>> mentioned in issue #4809.
>>
>> See also <URL: https://www.illumos.org/issues/6370 >,
>> <URL: https://www.illumos.org/issues/6513 > and
>> <URL: https://www.illumos.org/issues/6844 >.

And sadly yet another one:
https://www.illumos.org/issues/7176

> It seems there are several issues affecting zfs send/receive when the
> hole_birth feature is enabled.
> 
> Commit bc77ba7 fixes one of this issues, but not the others.
> 
> The best fix right now seems to completely ignore hole_birth. A patch
> was proposed here that ignores it, and adds a module parameter to enable
> it back [1].
> 
> Options I see going forward:
> 
> 1) Wait for the patch on PR #4833 to be merged, then import it
> defaulting to ignore hole_birth until the issue is fixed.
> 
> 2) If we don't want to wait for the patch to be merged, we can import it
> anyway but removing the part that adds a kernel module parameter tunable
> to avoid adding any option that is still not upstreamed. So just disable
> hole_birth always.
> 
> 3) Do nothing and wait for upstream to fix this issues with hole_birth
> and zfs send/receive.
> 
> 
> Right now, I'm inclined to proceed with option #2 and disable hole_birth
> until the issues with it are 100% fixed upstream and a new major release
> is made.
> 
> Opinions?

I would tend to agree with #2. Disable the *use of* hole_birth
unconditionally. That's a trivial and safe stop-gap for now. Then, once
the upstream bugs are resolved, revisit the issue and re-enable.

If it's trivial (and I haven't looked to see if it is), it might be wise
to also NOT enable hole_birth on new pools by default.

The biggest problem is that fixing these bugs only fixes *newly written
data*, so people with existing pools can still have data that will
result in corrupt sends. There have been some people talking about a new
"hole_birth_fix" (or "hole_birth2" or whatever) feature. This would take
the place of the original hole_birth TXG tracking feature; that is,
hole_birth would be ignored, and we would only honor hole birth times on
sends if the data was written after hole_birth_fix (rather than
hole_birth) was enabled.

> PS: There is still an user reporting some problems observed even with
> ignore_hole_birth=1, but is still not 100% clear if in this case the
> problem is the same. Let's wait some days to see how this evolves [2].
> 
> 
> BTW: I'm a bit surprised that this has been raised to RC bug on Debian
> unstable, but on Ubuntu LTS nobody cares about it. [3]
> Or I'm missing something?
> 
> 
> [1] https://github.com/zfsonlinux/zfs/pull/4833
> [2] https://github.com/zfsonlinux/zfs/issues/4809#issuecomment-238503468
> [3] https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1600060

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/attachments/20160811/37cac855/attachment.sig>