From mboxrd@z Thu Jan 1 00:00:00 1970 References: <2d496550-4609-0a26-489b-8721737c783b@redhat.com> <257A9B1C-04AC-4EDE-9671-9E7A60104F9F@gmail.com> From: Zdenek Kabelac Message-ID: <39ab5393-7667-901c-f2a1-f25f40d057f2@redhat.com> Date: Thu, 17 Sep 2020 21:32:07 +0200 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [linux-lvm] lvm limitations 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="utf-8"; format="flowed" To: LVM general discussion and development , Gionatan Danti Cc: =?UTF-8?Q?Tomas_Dalebj=c3=b6rk?= Dne 16. 09. 20 v 0:26 Gionatan Danti napsal(a): > Il 2020-09-15 23:47 Zdenek Kabelac ha scritto: >> Speaking of thin volumes - there can be at most 2^24 thin devices >> (this is hard limit you've ask for ;)) - but you have only� ~16GiB of >> metadata to store all of them - which gives you ~1KiB of data per such >> volume - >> quite frankly this is not too much� - unless as said - your volumes >> are not changed at all - but then why you would be building all this... >> >> That all said -� if you really need that intensive amount of snapshoting, >> lvm2 is likely not for you - and you will need to build something on your own, >> as you will need way more efficient and 'targeted' solution for your purpose. > > Thinvols are not activated by default - this means it should be not a big > problem managing some hundreds of them, as the OP ask. Or am I missing something? Hundreds should be 'fine' - but hundred thousands does mean the lvm2 metadata will reach GiB range - and this is definitely NOT fine ;) - since you would probably need around way more RAM to even manages this ;) and I'm not talking about some places with O^2 complexity in the lvm2 code... The metadata format is simply not going to fly here... Zdenek