Support Thin Provisioning with IDM locks in Device Mapper

[TProhofsky]

Thin pools do not use lvmlockd for allocation. Instead the device mapper allocates space from the pool. Need to investigate the device mapper using the lockmgr.

[Leo-Yan]

Some investigation for the thin pool and thin LV:

Conclusion

• Firstly, for the thin pool operations, I observed the consistent behavior for both sanlock and IDM after testing them.

• As you said, I can confirm that the thin pool and thin LV reuse the same lock; more specific, both of them use the thin pool's lock;

  This is proven by the code: lib/locking/lvmlockd.c, func _lockd_lv_thin().

• When activate a thin pool and its thin LV, though the lvm command "lvchange" will send command to lvmlockd to acquire the same lock for both thin pool and thin LV, lvmlockd will only send commands to IDM lock manager/drive firmware for the first locking operation, afterwards, it directly bails out if the lock has been acquired; except for the first locking operation, the later procedure is only finished on the host and no interaction for IDM lock manager and drive firmware.

• When deactivate the thin pool and thin LV, the lvm command will only send unlocking operation until the last user (here the user means the thin pool or the thin LV); so this is why we can acheive paired result for locking and unlocking.

  I understand the locking path uses function pool_is_active() to check the thin pool is active or not, if it's active, will directly bail out.

Problem

• Based on the testing, I don't find any logic error, either for the original code for LVM and sanlock, and I can see IDM lock manager handles the thin pool with the same way.

• I think one thing we can improve is to use dedicated locking for the thin pool and thin LVs. If we really move forward to this direction, one special thing is for the thin LV's lock, which should reuse the thin pool's PV list, this can allow LV's lock can cover more complete PV list as possible.

• Since the thin pool and thin LVs share the same one lock, if one host acquires the lock for any thin LV, this means any other hosts have no chance to use the thin pool and thin LVs.

• To be honest, I am a bit concern if we should move forward to allow every thin LV and thin pool use the dedicated locks, the reason is this issue seems to me is a common issue rather than a specific issue bound to a locking scheme. So if we want to move forward, means we need to change the the LVM core code rather than only change code only for IDM wrapper or IDM lock manager.