Bug 505370 - pvdisplay rounds the PV size incorrectly
pvdisplay rounds the PV size incorrectly
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Alasdair Kergon
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-11 12:35 EDT by bbobbo
Modified: 2009-06-11 13:05 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-11 13:05:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description bbobbo 2009-06-11 12:35:54 EDT
Description of problem:

pvdisplay only shows two decimal places when listing the PV size. If the thousandth's digit is a 5 and the hundredth's digit is even, the size gets rounded up to the next odd hundredth, which is incorrect.

For example, I have a Physical Volume which is 232.78G in size according to pvdisplay. I issue the command:

pvresize --setphysicalvolumesize 232.63G /dev/sde2

I do a pvdisplay, which shows:

  --- Physical volume ---
  PV Name               /dev/sde2
  VG Name               VolGroup_System
  PV Size               232.63 GB / not usable 4.93 MB
  Allocatable           yes
  PE Size (KByte)       32768
  Total PE              7444
  Free PE               6132
  Allocated PE          1312
  PV UUID               3G0rc8-t19k-YYp0-lkHL-dFEs-m6an-dMxW21

Seems fine. Then I check the size using system-config-lvm:

Properties for
Physical Volume

Physical Volume Name:  /dev/sde2
Volume Group Name:  VolGroup_System
Physical Volume Size:  232.62G
Space Used:  41.00G
Space Free:  191.62G
Total Physical Extents:  7444
Allocated Physical Extents:  1312
Attributes:  a-
PV UUID:  3G0rc8-t19k-YYp0-lkHL-dFEs-m6an-dMxW21

Why the 0.01G discrepancy? I calculate the size using 7444 total PEs * 32768 KB. This is 243924992 KB, which is 232.625 GB (according to Google: http://www.google.com/search?q=243924992+kilobytes+in+gigabytes). So obviously pvdisplay and system-config-lvm are rounding differently. They should use the same rounding method (the one I'm used to is the one used by system-config-lvm--round to an even number if the last digit is 5).

More generally, it seems to me that rounding values (for both pvdisplay and system-config-lvm) could cause problems when shrinking physical volumes and disk partitions, which is what I was in the process of doing. I don't know how fdisk, parted etc. handle sizes, but if my actual PV size is 232.625G, system-config-lvm tells me the PV size is 232.62G, and then I tell parted to resize the partition to 232.62G, is it smart enough to know that I actually mean 232.625G? Perhaps pvdisplay and system-config-lvm should not be displaying rounded values (or give the option to display non-rounded values)?

Version-Release number of selected component (if applicable):

How reproducible: Always

Steps to Reproduce:
1. Create a Physical Volume of 7444 total extents of size 32768KB
2. Check size using pvdisplay
3. Check size using system-config-lvm
Actual results:

The sizes do not agree.

Expected results:

The sizes should agree.

Additional info:
Comment 1 Alasdair Kergon 2009-06-11 13:05:52 EDT
If rounding matters to you in the lvm2 command line tools, use --units b (for example) and perform your own calculations.

      --units hsbkmgtHKMGT
              All   sizes   are   output  in  these  units:  (h)uman-readable,
              (s)ectors,  (b)ytes,  (k)ilobytes,   (m)egabytes,   (g)igabytes,
              (t)erabytes.  Capitalise to use multiples of 1000 (S.I.) instead
              of 1024.  Can also specify custom (u)nits e.g.  --units 3M

You'll find 'pvs' gives more control over the output than 'pvdisplay' too.

The rounding is performed within snprintf() in glibc and there are no plans to implement the rounding ourselves.

This reference might be relevant:

Closing this WONTFIX as it's never going to be worth our while spending the necessary time on this, but if somebody supplied clean and maintainable patches, they might well be accepted.

Note You need to log in before you can comment on or make changes to this bug.