On Mon, Nov 16, 2015 at 4:36 AM, Boris <[email protected]> wrote:
> I should have been more specific, in my case I see the problem with zvols: > the first snapshot has a non-zero block, the next snapshot has the block > overwrite with zeros, but the stream lacks the free record. The zvol is > ~1.2T, 64k block size, sparse, has lz4 compression on. > In that case I don't think your problem is related to the bug I mentioned, which only has to do with objects that have been reallocated. You must be seeing a different issue. We also can not reproduce your issue with a simple test case. --matt > > Typos courtesy of my iPhone > > On Nov 15, 2015, at 12:25 PM, Matthew Ahrens <[email protected]> wrote: > > 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 <[email protected]> > 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 <[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
