From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
Gionatan Danti <g.danti@assyoma.it>
Cc: "Tomas Dalebjörk" <tomas.dalebjork@gmail.com>
Subject: Re: [linux-lvm] lvm limitations
Date: Thu, 17 Sep 2020 21:32:07 +0200 [thread overview]
Message-ID: <39ab5393-7667-901c-f2a1-f25f40d057f2@redhat.com> (raw)
In-Reply-To: <cf779b76e25707b8ec3361f55318a1c7@assyoma.it>
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
next prev parent reply other threads:[~2020-09-17 19:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-29 23:25 [linux-lvm] lvm limitations Tomas Dalebjörk
2020-08-30 17:33 ` Zdenek Kabelac
2020-08-30 18:01 ` Gionatan Danti
2020-08-30 19:30 ` Zdenek Kabelac
2020-09-01 13:21 ` Gionatan Danti
2020-09-15 19:16 ` Tomas Dalebjörk
2020-09-15 20:08 ` Zdenek Kabelac
2020-09-15 21:24 ` Tomas Dalebjörk
2020-09-15 21:30 ` Stuart D Gathman
2020-09-15 22:24 ` Gionatan Danti
2020-09-15 21:47 ` Zdenek Kabelac
2020-09-15 22:26 ` Gionatan Danti
2020-09-16 4:25 ` Tomas Dalebjörk
2020-09-17 19:24 ` Zdenek Kabelac
2020-09-16 4:31 ` Tomas Dalebjörk
2020-09-16 4:58 ` Tomas Dalebjörk
2020-09-17 19:17 ` Zdenek Kabelac
2020-09-17 19:32 ` Zdenek Kabelac [this message]
2020-09-14 6:03 Tomas Dalebjörk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39ab5393-7667-901c-f2a1-f25f40d057f2@redhat.com \
--to=zkabelac@redhat.com \
--cc=g.danti@assyoma.it \
--cc=linux-lvm@redhat.com \
--cc=tomas.dalebjork@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.