From: Peter Rajnoha <prajnoha@redhat.com>
To: lvm-devel@redhat.com
Subject: pvresize problem
Date: Wed, 27 Mar 2013 10:23:17 +0100 [thread overview]
Message-ID: <5152BA85.1060001@redhat.com> (raw)
In-Reply-To: <20130326215001.GA15037@redhat.com>
On 26.03.2013 22:50, David Teigland wrote:
> On Tue, Mar 26, 2013 at 12:59:13PM -0400, David Teigland wrote:
>> I'm trying to verify shrinking with pvresize --setphysicalvolumesize
>>
>> When the pv is an orphan, it works as expected, but when the pv is
>> not an orphan, the resulting size is always 8192S less than the
>> requested size.
>
> Looking in _text_pv_resize(), I'm guessing the difference I see might be
> "pv->size -= size_reduction" which would indicate things are working as
> intended. If so, I'll adjust my checks to include this reduction.
>
Yes, exactly. When the PV is orphan, we're always reporting the size that
includes any alignments, metadata areas and PV headers (IOW, the "disk size
itself" or "pretended disk size" if the size was forced).
If the PV is in a VG, we're reporting only usable "data area" size, meaning the
size that is reserved for the data itself where extents can be allocated.
I can imagine this could cause confusion, but the problem is that it has been
reported this way since ages (though I don't know the exact historical reason
for this logic). The best would be if we could report the PV size for orphan
the same way as we do for non-orphans and then have an extra field that would
report the exact space used together with all the alignment and metadata...
(Though changing the PV size report for the orphan would mean changing existing
report which people can already use... Which is not a backward compatible
change unfortunately.)
Peter
prev parent reply other threads:[~2013-03-27 9:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 16:59 pvresize problem David Teigland
2013-03-26 21:50 ` David Teigland
2013-03-27 9:23 ` Peter Rajnoha [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=5152BA85.1060001@redhat.com \
--to=prajnoha@redhat.com \
--cc=lvm-devel@redhat.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.