We have a fix for this that we need to upstream. We are waiting on code reviews for another change to send/receive:
https://github.com/openzfs/openzfs/pull/23 6393 zfs receive a full send as a clone I'll probably stop waiting soon and RTI it, then we get get our fix for this in. --matt On Sun, Nov 15, 2015 at 8:37 AM, Boris <[email protected]> wrote: > Hi, guys, > > > I've been looking an issue where sometimes, after non-zero data blocks > are overwritten with zero blocks with compression on, the corresponding > incremental send stream does not include the FREE record for those blocks. > The zdb -ddddddd output seems to indicate that the blocks in question have > never been written (the offsets for them are not listed in the output). > > > This looks like the issue addressed by > > > commit a4069eef2e403a3b2a307b23b7500e2adc6ecae5 > > Author: Prakash Surya <[email protected]> > > Date: Fri Mar 27 13:03:22 2015 +1100 > > > Illumos 5695 - dmu_sync'ed holes do not retain birth time > > > but I certainly do have that commit. I have experimented with overwriting > blocks at different offsets, ranges of blocks spanning L1 and L2 block > pointers, but I cannot reproduce the issue. > > > Any suggestions for directions to look ? Perhaps for a way to shape the > block tree such that this problem could arise ? > > > Best regards, > > Boris. > > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
