[linux-lvm] Possible bug in expanding thinpool: lvextend doens't expand the top-level dm-linear device

Zdenek Kabelac zkabelac at redhat.com
Sat Jan 2 23:05:06 UTC 2016

Dne 1.1.2016 v 19:10 M.H. Tsai napsal(a):
> 2016-01-01 5:25 GMT+08:00 Zdenek Kabelac <zkabelac at redhat.com>:
>> You should be aware of  thin-pool limits.
>> i.e. ATM it's bad plan to use more then say 16 LVs in parallel for
>> a single thin-pool LV - it cannot be used in some massive parallel system
>> for its current locking mechanism.
> Is it LVM or dm-thin kernel target's limit? And, is there any
> reference about the "16 LVs" and the locking issue? (why 16 LVs?)


That's rather Joe (driver author) what are the 'reasonable' limits for current 
target? (I think I remember it correctly it's been somewhere 16-32 LV).

Of course it all depends on uses case - and any reproducible benchmarks
are welcome in this area (e.g. there is no hard limit on some device number
count - but the more parallel writes it need to handle and do provisioning,
trimming the more lock contention will happen)

>> There is even sequencing problem with creating snapshot in kernel target
>> which needs to be probably fixed first.
>> (the rule here should be - to never create/allocate something when
>> there is suspended device - and this rule is broken with current thin
>> snapshot creation - so thin snap create message should go in front
>> to ensure there is a space in thin-pool ahead of origin suspend  - will
>> be addressed in some future version....)
>> However when taking snapshot - only origin thin LV is now suspended and
>> should not influence rest of thin volumes (except for thin-pool commit
>> points)
> Does that mean in future version of dm-thin, the command sequence of
> snapshot creation will be:
> dmsetup message /dev/mapper/pool 0 "create_snap 1 0"
> dmsetup suspend /dev/mapper/thin
> dmsetup resume /dev/mapper/thin

Possibly different message - since everything must remain
fully backward compatible (i.e. create_snap_on_suspend,
or maybe some other mechanism will be there).
But yes something in this direction...



More information about the linux-lvm mailing list