Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1059558 - Unnecessary precision in partition sizes in custom partitioning
Summary: Unnecessary precision in partition sizes in custom partitioning
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-30 07:53 UTC by Adam Williamson
Modified: 2015-01-20 17:44 UTC (History)
6 users (show)

Fixed In Version: anaconda-21.34-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-20 17:44:58 UTC


Attachments (Terms of Use)

Description Adam Williamson 2014-01-30 07:53:39 UTC
In current Rawhide, the right-hand pane of custom partitioning seems to like to go into really a *lot* of detail about how big partitions are...see https://www.happyassassin.net/blog/20140129_f21_part_2.png , for e.g. - good to know it'll be exactly 7.667936801910400390...is that a 6?...something GiB, but I could probably live with 7.67 :)

I let blivet determine the size of that volume for me, btw - I created /boot and swap with specific sizes, then left the size of / blank to let it fill the rest of the disk.

I guess rounding got lost somewhere along the way with recent changes?

Comment 1 David Lehman 2014-01-30 15:42:14 UTC
That does seem a bit over the top. What you can expect to see is partitions with precision to at least 1 MiB:

>>> Size(spec="1MiB").convertTo("GiB")
Decimal('0.0009765625')

For lvm, precision to the extent size (default: 4 MiB) is required:

>>> Size(spec="4MiB").convertTo("GiB")
Decimal('0.00390625')


We used to (try to) store sizes as MiB, usually as an integer. That made things really simple a lot of the time. Now we store them as bytes. We did not add code to ignore precision beyond, say, 1 MiB. I suppose we could do that to make the UI look nicer.

Comment 2 Adam Williamson 2014-01-30 17:05:31 UTC
I guess as long as it can be done strictly for display, so it doesn't risk re-introducing the kind of problems the switch to bytes was meant to produce...

Comment 3 Adam Williamson 2014-01-30 17:05:46 UTC
er, resolve :)

Comment 4 David Lehman 2014-01-30 17:39:44 UTC
That's part of the problem: we don't have a way to display with reduced precision without also actually losing that precision. IOW the data you see in the UI is the actual data -- not an abstraction or copy of it.

Comment 5 Adam Williamson 2014-01-30 19:12:54 UTC
Ah :/ if we have to choose, then, it's probably better to prioritize simplicity/reliability/cleanliness over prettiness in the UI (we've had enough experience with that one, I think). If it can be abstracted out that'd be great, but obviously there may be other things that take precedence (hence marking this bug's severity as 'low'), and I don't know how much work it'd be.

Comment 6 David Lehman 2015-01-20 17:44:58 UTC
Fixed in anaconda-21.34-1 with a followup in anaconda-22.5-1 to reduce displayed precision for container sizes.


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