ZoL: merge in large dnode feature fixes
illumos is missing a few small follow up ZoL bug fixes for the large dnode feature. We should pull those in.
Those commits are in the ZoL tree as (newest to oldest):
PR 8435 - 75d6b7ddca269542279975f716a343bb40a79baf - Add missing copyright notice to large_dnode tests
PR 7433 - e14a32b1c844d924b9f093375c0badcf10f61741 - Fix object reclaim when using large dnodes
PR 6616 - 48fbb9ddbf2281911560dfbc2821aa8b74127315 - Free objects when receiving full stream as clone
PR 6695 - 39f56627ae988d09b4e3803c01c22b2026b2310e - receive_freeobjects() skips freeing some object
Updated by Joshua M. Clulow about 3 years ago
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
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
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
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
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.
Updated by Electric Monk about 3 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 946342a260bbae359b48bf142ec1fe40792ee862 Author: Fabian Grünbichler <email@example.com> Date: 2019-03-04T06:40:45.000Z 10452 ZoL: merge in large dnode feature fixes Portions contributed by: Ned Bass <firstname.lastname@example.org> Portions contributed by: Tom Caputi <email@example.com> Reviewed by: Giuseppe Di Natale <firstname.lastname@example.org> Reviewed by: Alek Pinchuk <email@example.com> Reviewed by: Brian Behlendorf <firstname.lastname@example.org> Reviewed by: Paul Dagnelie <email@example.com> Reviewed by: George Melikov <firstname.lastname@example.org> Reviewed by: Giuseppe Di Natale <email@example.com> Reviewed by: Toomas Soome <firstname.lastname@example.org> Reviewed by: Andy Fiddaman <email@example.com> Reviewed by: Gergő Mihály Doma <firstname.lastname@example.org> Reviewed by: Jerry Jelinek <email@example.com> Approved by: Joshua M. Clulow <firstname.lastname@example.org>