From mboxrd@z Thu Jan 1 00:00:00 1970 References: <567BB51A.4070101@redhat.com> <567D8CE9.3030101@redhat.com> <5682F5F2.1000804@redhat.com> <56859D38.6090000@redhat.com> From: Zdenek Kabelac Message-ID: <568857A2.7080807@redhat.com> Date: Sun, 3 Jan 2016 00:05:06 +0100 MIME-Version: 1.0 In-Reply-To: Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] Possible bug in expanding thinpool: lvextend doens't expand the top-level dm-linear device Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: LVM general discussion and development , Joe Thornber Dne 1.1.2016 v 19:10 M.H. Tsai napsal(a): > 2016-01-01 5:25 GMT+08:00 Zdenek Kabelac : >> 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