linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: Joshua Long <joshualong@microsoft.com>
Cc: "linux-lvm@lists.linux.dev" <linux-lvm@lists.linux.dev>
Subject: Re: Question on Computing VG Capacity
Date: Thu, 7 Aug 2025 12:46:36 -0500	[thread overview]
Message-ID: <aJTmfPOQIv3JdwGG@redhat.com> (raw)
In-Reply-To: <LV3PR21MB4252594D194D3081D1E50411C12DA@LV3PR21MB4252.namprd21.prod.outlook.com>

On Wed, Aug 06, 2025 at 09:49:53PM +0000, Joshua Long wrote:
> Hi everyone,
> 
> I wanted to reach out with a question regarding how to compute the exact usable capacity of a volume group, based on the disks that will be used, without actually creating the VG or physical volumes.
> 
> Specifically, I am looking for a method or tool that can help me determine the capacity accurately beforehand. 
> 
> For example, I have a VG with a single PV with a PE size of 4194304 B. 
> 
> We have one disk with 1920383410176 B, which equals 457855.084 PE. 
> 
> The capacity of the VG with this PV after creation is 1920378863616 B, equaling 457854 PE.
> 
> Is it always true that the total PEs in the VG will be the disk capacity divided by PE size, minus one? Or are there other factors or metadata overheads I should consider? Any guidance or suggestions would be greatly appreciated.

Hi, 

It would require some effort to track down all the factors in the code
that might come into play, so I can't immediately state a firm answer.
A few variables come to mind which might influence the result (basically
through attempts to align things nicely): the system's page size, the
device's minimum_io_size and optimal_io_size, and the device size being a
multiple of the extent size.  The pvcreate man page explains some of this
under "Metadata location, size, and alignment".  It also mentions command
options that you can use to control the end result.  By using those
options, and rounding the device size, I expect you should be able to
predict the total PEs accurately.

Dave


      reply	other threads:[~2025-08-07 17:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <LV3PR21MB4252B491DCFB134F050577BEC12DA@LV3PR21MB4252.namprd21.prod.outlook.com>
2025-08-06 21:49 ` Question on Computing VG Capacity Joshua Long
2025-08-07 17:46   ` David Teigland [this message]

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=aJTmfPOQIv3JdwGG@redhat.com \
    --to=teigland@redhat.com \
    --cc=joshualong@microsoft.com \
    --cc=linux-lvm@lists.linux.dev \
    /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 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).