@stevenburgess It's still in review internally (mostly regarding changes to
zfs_send_007_pos.ksh et al), but when we push here, it'll be that version.
Thanks for confirming it works on your end!
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/37#is
@stevenburgess Good sanity check. It turns out that zfs_send_007_pos.ksh is
bugged; the `diff -r` needs a log_must statement, so it wasn't actually failing
the test if there was an error. Once I fixed the test, I discovered that you
guys are right; this patch doesn't fix the issue in all cases
It seems like you guys have been running into an issue with ZoL with regards
to zfs_send_007.ksh, since it works correctly on illumos machines, even with
the pool version set to 28. Unfortunately, I can't run the problem script that
@stevenburgess created; it fails on illumos because there is
Bprotopopov: re dnode_sync.c:dnode_sync(), I don't think we're guaranteed that
those blkptrs in the dnode have a birth time. It's possible 1) that the system
doesn't have hole birth enabled, and maybe 2) that those blkptrs were there
when the file was created, and so don't have a birth time? (
The same bug is fixed by this patch. Your bug probably results from line 551
in dmu_traverse.c, where traverse assumes that hole birth was enabled at txg 0
if it isn't enabled, rather than at txg UINT64_MAX as it should.
This bug is present on all platforms, not just ZoL; all files in ZFS are
veloper mailing list
> developer@open-zfs.org
> http://lists.open-zfs.org/mailman/listinfo/developer
>
--
Paul Dagnelie
___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
bit
> confusing since we have a full stream. Maybe it would have better to
> return
> EEXIST signalling that the target filesystem exists.
>
--
Paul Dagnelie
___
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
