Actions
Bug #11943
closed
Fix out-of-order ZIL txtype lost on hardlinked files
Start date:
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:
Description
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 <david.chen@nutanix.com>
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 Andy Fiddaman over 3 years ago
With the ZoL fix in place, the new slog tests pass (they failed before)
Test: /opt/zfs-tests/tests/functional/slog/slog_replay_fs_001 (run as root) [00:11] [PASS] Test: /opt/zfs-tests/tests/functional/slog/slog_replay_fs_002 (run as root) [00:22] [PASS]
Updated by Electric Monk over 3 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit d8849d7dee03b84a3fa281ec65eb9e3d86d3756b
commit d8849d7dee03b84a3fa281ec65eb9e3d86d3756b
Author: Chunwei Chen <david.chen@nutanix.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 <ryan@freqlabs.com>
Portions contributed by: Andy Fiddaman <andy@omniosce.org>
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Reviewed by: Toomas Soome <tsoome@me.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Actions