Fix out-of-order ZIL txtype lost on hardlinked files
When replaying ZIL records involving the removal of a link from a hardlinked file, the code erroneously determines that the object was completely removed, causing dropped replay operations.
ZoL has a fix for this and an associated test.
commit 8e556c5ebc7b66caf2cdcc561b6644f9f8437a6d Author: Chunwei Chen <firstname.lastname@example.org> Date: Tue Aug 13 20:21:27 2019 -0700 Fix out-of-order ZIL txtype lost on hardlinked files We should only call zil_remove_async when an object is removed. However, in current implementation, it is called whenever TX_REMOVE is called. In the case of hardlinked file, every unlink will generate TX_REMOVE and causing operations to be dropped even when the object is not removed. We fix this by only calling zil_remove_async when the file is fully unlinked.
Updated by Electric Monk 10 days ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
commit d8849d7dee03b84a3fa281ec65eb9e3d86d3756b Author: Chunwei Chen <email@example.com> Date: 2019-11-11T20:21:17.000Z 11943 Fix out-of-order ZIL txtype lost on hardlinked files 11942 Panic on zil/slog replay when TX_REMOVE followed by TX_CREATE Portions contributed by: Ryan Moeller <firstname.lastname@example.org> Portions contributed by: Andy Fiddaman <email@example.com> Reviewed by: Jerry Jelinek <firstname.lastname@example.org> Reviewed by: Toomas Soome <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>