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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux