GNOME Bugzilla – Bug 612928
file size units not consistent with GNOME desktop
Last modified: 2020-11-13 10:41:30 UTC
The file size units are not consistent with GNOME desktop. gparted should use g_format_size_for_display() for formatting the sizes.
Created attachment 156165 [details] [review] units_consistency.patch
Thank you for your interest in GParted, bringing this to my attention, and for providing a patch. Currently much of the GParted code assumes a sector size of 512 bytes. I am working to enhance GParted to work with sector sizes greater than 512 bytes. As such I plan to hold off considering the proposed patch until I am finished with reworking the code for bug #607165 - "Add support for devices with sector sizes greater than 512 bytes". With the fundamental change to the code required to address bug #607165, I wish to minimize other changes as much as possible during this transition.
We have an units policy in Ubuntu [1]. We patched g_format_size_for_display() to comply with the policy, but this break compatibility. We reverted the patch and consider g_format_size_for_display() as deprecated. Therefore I am not sure any more, whether this patch should be applied. I am working on a set of functions that should replace g_format_size_for_display() (bug #554172). For now, I request to work internally with bytes. This will ease the migration later. [1] https://wiki.ubuntu.com/UnitsPolicy
Thanks for the link to the other bug report. It would probably be best for this other bug report to land on a solution and the solution be adopted before the code for GParted is changed.
Seconded.
Changing GParted to use decimal prefixes is wrong anyway, as partition start/stop/size certainly have to be entered/shown with binary prefixes when editing; doing otherwise would be very inconventient and result in bugs (and maybe data loss).
Jan raises a good point. For partitioning, we are very much interested in placing partition boundaries on values based on a power of 2, and not a power of 10. This is especially important with RAID devices, and newer Solid State Drives for performance reasons.
Partition boundaries on values based on a power of 2? You want me to use 256 GiB instead of 200 GiB as partition size or how far is this base 2 approach going?
The boundaries must lie at a minimum at the sector level (e.g., 512 bytes, 2048 bytes, 4096 bytes). These values cannot be multiples of 10 (e.g., 500 bytes, 2000 bytes, 4000 bytes).
The value should be rounded to the next boundary. Imagine a partition with a size of 20 GB = 20,000,000,000 byte rounded to 20,000,002,048 or 19,999,997,952 bytes. This is a difference of 0.0001 %. Normal users can live with this, can't they?
Historical rounding of partitions places them on the cylinder boundary for performance reasons. With today's large hard drives this is at values that are evenly divisible by the following: (255 heads) * (63 sectors) * (512 bytes / sector) = 8,225,280 bytes = 7.84 MiB For newer operating systems, Solid State Drives, or RAID systems, the proposed recommendation is to place the partition boundary exactly on a MiB value. For example 1,048,576 bytes = 1.0 MiB. This too is for performance reasons. Much of this precise positioning can be performed behind the scenes. If GParted is to display MB instead of MiB values, then it should also take as input MB instead of MiB values. I believe the patch in comment #1 addresses only the output portion of this change.
(In reply to comment #11) > Much of this precise positioning can be performed behind the scenes. If > GParted is to display MB instead of MiB values, then it should also take as > input MB instead of MiB values. I believe the patch in comment #1 addresses > only the output portion of this change. Yes. Ignore my first patch. I will work on a solution that supports input and output and gives the user the option to select the preferred unit.
Cool. Having the option of selecting the units is much better than having to settle for one or the other. :)
Furthermore, I would be very nice (and practical) that GParted use the same units (whether it would be bytes, KiB, MiB, GiB, TiB, sectors, cylinders) all over the application (preferably configurable). The current situation of using different units in view/edit operations is somewhat confusing and forces people like me (who likes to have partition sizes rounded) to have calculator at hand.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/gparted/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).