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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 1.1.2016 v 19:10 M.H. Tsai napsal(a):
> 2016-01-01 5:25 GMT+08:00 Zdenek Kabelac <zkabelac@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?)

Hi

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...

Regards

Zdenek