Notes from original commits and review¶

PR 8435 75d6b7dd Add missing copyright notice to large_dnode tests¶

Pull Request: https://github.com/zfsonlinux/zfs/pull/8435

Commit: https://github.com/zfsonlinux/zfs/commit/75d6b7ddca269542279975f716a343bb40a79baf

    Add missing copyright notice to large_dnode tests

    Missing copyright notices were noticed during the Illumos
    RTI process. Add LLNS 2016 copyright based on original merge
    date.

PR 7433 e14a32b1 Fix object reclaim when using large dnodes¶

Pull Request: https://github.com/zfsonlinux/zfs/pull/7433

Commit: https://github.com/zfsonlinux/zfs/commit/e14a32b1c844d924b9f093375c0badcf10f61741

    Fix object reclaim when using large dnodes

    Currently, when the receive_object() code wants to reclaim an
    object, it always assumes that the dnode is the legacy 512 bytes,
    even when the incoming bonus buffer exceeds this length. This
    causes a buffer overflow if --enable-debug is not provided and
    triggers an ASSERT if it is. This patch resolves this issue and
    adds an ASSERT to ensure this can't happen again.

PR 6616 48fbb9dd Free objects when receiving full stream as clone¶

Pull Request: https://github.com/zfsonlinux/zfs/pull/6616

Commit: https://github.com/zfsonlinux/zfs/commit/48fbb9ddbf2281911560dfbc2821aa8b74127315

    Free objects when receiving full stream as clone

    All objects after the last written or freed object are not supposed to
    exist after receiving the stream.  Free them accordingly, as if a
    freeobjects record for them had been included in the stream.

PR 6695 39f56627 receive_freeobjects() skips freeing some object¶

Pull Request: https://github.com/zfsonlinux/zfs/pull/6695

Commit: https://github.com/zfsonlinux/zfs/commit/39f56627ae988d09b4e3803c01c22b2026b2310e

    receive_freeobjects() skips freeing some objects

    When receiving a FREEOBJECTS record, receive_freeobjects()
    incorrectly skips a freed object in some cases. Specifically, this
    happens when the first object in the range to be freed doesn't exist,
    but the second object does. This leaves an object allocated on disk
    on the receiving side which is unallocated on the sending side, which
    may cause receiving subsequent incremental streams to fail.

    The bug was caused by an incorrect increment of the object index
    variable when current object being freed doesn't exist.  The
    increment is incorrect because incrementing the object index is
    handled by a call to dmu_object_next() in the increment portion of
    the for loop statement.

    Add test case that exposes this bug.

Review: https://www.illumos.org/rb/r/1515/

Testing Notes¶

Kody says he ran the zfs-test suite with this change.

Joshua Clulow wrote:

Testing Notes¶

Kody says he ran the zfs-test suite with this change.

could you post/share report about: how much tests have been done in suite , how much FAIL, how much SKIP