archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <>
To: "Tomas Dalebjörk" <>,
	"Gionatan Danti" <>
Cc: LVM general discussion and development <>
Subject: Re: [linux-lvm] lvm limitations
Date: Tue, 15 Sep 2020 22:08:13 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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
active LVs...)

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 
experience ;)

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....



  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

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:

* 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).