btw, here is the bug you're asking about: https://www.illumos.org/issues/6370
--matt On Sun, Nov 15, 2015 at 9:24 AM, Matthew Ahrens <mahr...@delphix.com> wrote: > 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 <bprotopo...@hotmail.com> 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 <prakash.su...@delphix.com> >> >> 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 >> developer@open-zfs.org >> http://lists.open-zfs.org/mailman/listinfo/developer >> >> >
_______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
