From: Zdenek Kabelac <firstname.lastname@example.org>
To: "Tomas Dalebjörk" <email@example.com>,
"Gionatan Danti" <firstname.lastname@example.org>
Cc: LVM general discussion and development <email@example.com>
Subject: Re: [linux-lvm] lvm limitations
Date: Tue, 15 Sep 2020 22:08:13 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Dne 15. 09. 20 v 21:16 Tomas DalebjÃ¶rk napsal(a):
> thanks for the feedback
> in previous older versions of LVM, I guess that each lv requires a minor, major and these are might have limitations of how many can be addressed
> but how about LVM2?
> if I intend to have many hundred thousands of LV, would that be any issue?
If you are asking about these limits -
major number is 12bits 4096
minor number is 20bits 1048576
Since DM uses 1 single major - you are limited to ~1 million active LVs.
But I assume system would be already slowed down to unsable level
if you would ever reach 100 000 devices on a single system.
(but you will experience major system slow-down with even just 10000
So as had been said - sensible/practical limit for lvm2 is around couple
thousands of LVs. You can use 'more' but it would be more and more painful
If you would have enough time :) and massive CPU power behind -
you probably can even create VG with 1 million LVs - but the usability
of such VG would be really for long-suffering users ;)
So yes hundred thousands of LVs in a single VG would be a BIG problem,
but I don't see any useful use-case why anyone would need to manipulate
with so many device within a single VG.
And if you really need hundred thousands - you will need to write much more
efficient metadata management system...
And purely theoretically it's worth to note there is nontrivial amount of
kernel memory and other resources needed per single device - so to run with
million devices you would probably need some expensive hw (many TiB of RAM...)
just to make the available - and then there should be some caching and
something to use them....
next prev parent reply other threads:[~2020-09-15 20:08 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 [this message]
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
2020-09-14 6:03 Tomas Dalebjörk
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).