Reviewed by: Matthew Ahrens <mahr...@delphix.com> Reviewed by: George Wilson <george.wil...@delphix.com>
Description A scenario came up where a callback executed by vdev_indirect_remap() on a vdev, calls vdev_indirect_remap() on the same vdev and tries to reacquire vdev_indirect_rwlock that was already acquired from the first call to vdev_indirect_remap(). The specific scenario, is that we want to remap a block pointer that is snapshoted but its dataset's remap_deadlist is not cached. So in order to add it we issue a read through a vdev_indirect_remap() on the same vdev, which brings up the aforementioned issue. Potential Solutions 1] Change vdev_indirect_rwlockto be recursive. Our locking strategy remains the same 2] Introduce a mechanism similar to ds_pending_deadlist (of ds_deadlist) to ds_remap_deadlist. 3] Grab the lock, copy the relevant indirect mapping entries in a buffer, and drop it before doing any further processing. Solution Proposed by this change We've decided to go with the third option mentioned above. The main advantages of it being the following: - we hold the lock for less time - Conceptually simpler in terms of locking. The lock only protects the vdev's indirect mapping and nothing else - More flexible as a locking strategy in general. The lock does not guide what the callbacks should and should not do in terms of I/O anymore - if not less complex than solutions [2], then definitely more localized Related Bugs: DLPX-49245 You can view, comment on, or merge this pull request online at: https://github.com/openzfs/openzfs/pull/542 -- Commit Summary -- * 9080 recursive enter of vdev_indirect_rwlock from vdev_indirect_remap() -- File Changes -- M usr/src/uts/common/fs/zfs/vdev_indirect.c (108) -- Patch Links -- https://github.com/openzfs/openzfs/pull/542.patch https://github.com/openzfs/openzfs/pull/542.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/542 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Tca43f609ceed4c33-M5bb02fe8c58447210e74aa9f Powered by Topicbox: https://topicbox.com