Commits on Feb 8, 2018

1. 9080 recursive enter of vdev_indirect_rwlock from vdev_indirect_remap() …

   Reviewed by: Matthew Ahrens <mahrens@delphix.com>
   Reviewed by: George Wilson <george.wilson@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

   

   sdimitro committed Feb 8, 2018
   Copy the full SHA

   a15e295 View commit details

   Browse the repository at this point in the history