GNOME Bugzilla – Bug 684034
Reconsider the keeping of 1 MiB preceding free space for all partition creations
Last modified: 2013-03-23 18:19:06 UTC
I have tried your current application out a bit from a fresh CD "Parted Magic 2012_09_12". I stumble on a specific detail in the partition creation dialogue once again. I would like to decrease the number in the field "Free space preceding (MiB)" to zero for a new data partition. But this input is always reset to the value "1" for the selected disk "/dev/sdb". I assume that this handling might be related to details from issues around terms "MBR gap" or "embedding area" like the following. - Report "warn if grub is not likely to fit in using the current disk layout" https://bugzilla.redhat.com/show_bug.cgi?id=737508 - Article "Windows applications making GRUB 2 unbootable" by Colin Watson http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html - Section "BIOS installation" http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html I suggest to make the specification of such storage spaces which should intentionally not be assigned to bootable partitions better configurable.
When creating a partition at the start of a disk, or any logical partition, the GParted GUI has been hard coded to reserve 1 MiB of space for the Master Boot Record (MBR), and Extended Boot Record (EBR) respectively. This is because the smallest allocatable unit of space in GParted is 1 MiB. The actual amount of space reserved as unallocated in front of these partitions will vary depending upon other factors such as: - the alignment chosen - the start of the extended partition - the end of a preceding logical partition With Cylinder alignment, one track (normally 63 sectors) is reserved at the front of the disk for the partition table and possible boot code. With MiB alignment, which is the default for new operating systems, a full 2048 sectors is reserved. This is assuming a 512 byte sector size. With GUID Partition Tables (GPT) GParted also reserves up to 1 MiB of unallocated space at the end of the drive for the backup GPT. Since new operating systems default to MiB alignment, and because MiB alignment works well with new disk devices, there does not appear to be a good reason to make this reserved space more configurable. Why do you wish to change these default values?
(In reply to comment #1) > When creating a partition at the start of a disk, or any logical partition, the > GParted GUI has been hard coded to reserve 1 MiB of space for the Master Boot > Record (MBR), and Extended Boot Record (EBR) respectively. This is because the > smallest allocatable unit of space in GParted is 1 MiB. I find this implementation detail wrong. I see a need for adjustments of this setting. > Since new operating systems default to MiB alignment, and because MiB alignment > works well with new disk devices, there does not appear to be a good reason to > make this reserved space more configurable. Would you like to support all existing (and older) partition configurations? See also the issue "Improve knowledge presentation about partitions" (bug #539185). Do you really want to exclude any fine-tuning options?
(In reply to comment #2) > (In reply to comment #1) > > When creating a partition at the start of a disk, or any logical > > partition, the GParted GUI has been hard coded to reserve 1 MiB of > > space for the Master Boot Record (MBR), and Extended Boot Record (EBR) > > respectively. This is because the smallest allocatable unit of space > > in GParted is 1 MiB. > > I find this implementation detail wrong. I see a need for adjustments of this > setting. If this value were set to zero, then the actual size of the partition created would be 1 MiB smaller than the GUI indicated assuming the default MiB alignment is used. The reason is that unallocated space must be reserved for the MBR or EBR. The actual size reserved will depend on the alignment chosen by the user. If your intention was to have a value greater than 0 MiB, but smaller than 1 MiB, then that is more along the lines of allowing data entry in values such as sectors, MB, GiB. At the moment the closest bug report to this that I can find is Bug #612928 - file size units not consistent with GNOME desktop. > > Since new operating systems default to MiB alignment, and because MiB > > alignment works well with new disk devices, there does not appear to > > be a good reason to make this reserved space more configurable. > > Would you like to support all existing (and older) partition configurations? > See also the issue "Improve knowledge presentation about partitions" (bug > #539185). > > Do you really want to exclude any fine-tuning options? Currently the alignment options control the value of the actual starting sector. By this I mean that even if the GUI were adjusted to allow 0 MiB Free Space Preceding, the actual unallocated free space preceding would be adjusted for cylinder or MiB alignment. Hence permitting a setting of 0 MiB preceding free space would not change the starting sector value used when an MBR or EBR is required. Please note that when creating subsequent primary partitions (or an extended partition) that are not at the start of the drive, the default free space preceding value is 0 MiB. This is because these partitions do not require an MBR or EBR. Is your intention to have an alignment scheme other than Cylinder or MiB?
(In reply to comment #3) > The reason is that unallocated space must be reserved for the MBR or EBR. This specific storage space is only needed if a user wants to boot ever from there, isn't it? I suggest to introduce device-specific memory allocation settings. It would also eventually include options like the size for an "embedding area". > If your intention was to have a value greater than 0 MiB, but smaller than 1 > MiB, then that is more along the lines of allowing data entry in values such as > sectors, MB, GiB. Yes, that is the fine-tuning I would appreciate to become supported. See also the issue "Support for data entry and display of logical blocks (sectors)" (bug #622150). > Is your intention to have an alignment scheme other than Cylinder or MiB? Not yet. - Other users might be interested in further units.
(In reply to comment #4) > (In reply to comment #3) > > The reason is that unallocated space must be reserved for the MBR or EBR. > > This specific storage space is only needed if a user wants to boot ever from > there, isn't it? This specific storage space is needed regardless of if a user wants to boot from the drive. The MBR and EBR structures are what define an MSDOS partition table. Without the MBR, there is no MSDOS partition table, and hence no partitions. The MBR contains records for the initial 4 partitions. An EBR tracks each logical partition. See: http://en.wikipedia.org/wiki/Master_boot_record http://en.wikipedia.org/wiki/Extended_boot_record Does this help explain why this specific storage space is required?
(In reply to comment #5) > This specific storage space is needed regardless of if a user wants to boot > from the drive. Would you like to consider storage devices with which the provided space might be used as one piece completely (without various boot records)? Does the famous Microsoft DOS partitioning format support it that a partition starts at the second sector/block eventually? Would it make sense to make "unused areas" configurable that belong to logical partitions?
(In reply to comment #6) > (In reply to comment #5) > > This specific storage space is needed regardless of if a user wants to boot > > from the drive. > > Would you like to consider storage devices with which the provided space might > be used as one piece completely (without various boot records)? This would be the case where the entire device is treated as raw, or the entire device is formatted with a file system. In these situations there is no partition table. Since there is no partition table, in these situations there is no need for the GParted for editing partition tables. > Does the famous Microsoft DOS partitioning format support it that a partition > starts at the second sector/block eventually? GNU/Linux requires a minimum of 2 sectors for the boot record (at least with EBRs). Since many tools assume that more unallocated sectors are available (at least the first 63), it is less safe to try to use these sectors when the device is formatted with a partition table. > Would it make sense to make "unused areas" configurable that belong to logical > partitions? The amount of "unused areas" is very small in comparison to the size of modern disk devices. One of the main reasons that this space is not used is for performance. With old hard drives the Cylinders/Heads/Sectors reported by the device matched the physical configuration of the device. As such for performance reasons partitions were aligned to cylinders to reduce disk head seeks. With modern hard drives, there is a deviation away from the old 512 bytes per sector standard. These modern devices support 2048, 4096, and higher bytes per sector. To ensure optimum performance, major industry players have chosen to align partitions to mebibyte (MiB) boundaries. Aligning partitions to MiB boundaries works well for all modern disk devices. In conclusion, it does not make sense to make the "unused areas" configurable because the amount of space "lost" is small, and there would be a loss in device performance. I do not see a good reason to implement this request. Do you have a good reason? If not then we should close this report as "RESOLVED - NOTABUG" since the 1 MiB preceding free space is a design choice.
(In reply to comment #7) > Do you have a good reason? I suggest to be more careful about space handling just because of progress with "modern" stuff. I would appreciate if storage devices can still be fine-tuned even if they are not measured in the modern giga-/terabyte range. Are you interested in backward compatibility (for affected "older" devices)? Would you like to be able to create small test partitions (a few KiB or MiB in size) without introducing modern layout recommendations?
(In reply to comment #3) > Please note that when creating subsequent primary partitions > (or an extended partition) that are not at the start of the drive, > the default free space preceding value is 0 MiB. If I would like to add a second logical partition to one of my hard disks, the graphical user interface insist on the input value "1 MiB preceding free space" by default even if I try out alignment selection "none" or "Cylinder".
(In reply to comment #8) > I suggest to be more careful about space handling just because of progress > with "modern" stuff. I would appreciate if storage devices can still be > fine-tuned even if they are not measured in the modern giga-/terabyte range. > Are you interested in backward compatibility (for affected "older" devices)? GParted does support the older device standard of Cylinder alignment. > Would you like to be able to create small test partitions (a few KiB or MiB > in size) without introducing modern layout recommendations? No. The reason is because many file systems can not be created in under a MiB. For example the FAT16 file system requires a partition of at least 16 MiB. (In reply to comment #9) > If I would like to add a second logical partition to one of my hard disks, the > graphical user interface insist on the input value "1 MiB preceding free space" > by default even if I try out alignment selection "none" or "Cylinder". As I indicated before, the GUI default of 1 MiB of space is purposely coded into the GUI. This enables the selection of Align to "None" to work. Otherwise creation of a logical partition would fail because unallocated space _must_ be reserved for the EBR. If Align to "Cylinder" is chosen then GParted will align the partition to the nearest cylinder, which might be up to 8 MiB from the end of the previous partition. The use of cylinder alignment, or MiB alignment are the expected way for partitions to be aligned for old and new operating systems respectively. So far I still do not see a reason to change the GUI default. Where do you want your partitions to start that requires changing this 1 MiB GUI default?
(In reply to comment #10) > As I indicated before, the GUI default of 1 MiB of space is purposely coded > This enables the selection of Align to "None" to work. Does this wording indicate a special dependency between these settings? > Otherwise creation of a logical partition would fail because unallocated space > _must_ be reserved for the EBR. Can these "unused areas" (traditional 63 sectors/blocks?) be smaller than 1 MiB? > If Align to "Cylinder" is chosen then GParted will align the partition to > the nearest cylinder, which might be up to 8 MiB from the end of > the previous partition. Does this mean that the free space around the selected partition can eventually not be represented by an integer MiB value? > Where do you want your partitions to start that requires changing this > 1 MiB GUI default? They can begin and end at every position as usual as the selected alignment unit would allow.
(In reply to comment #11) > (In reply to comment #10) > > As I indicated before, the GUI default of 1 MiB of space is purposely coded > > This enables the selection of Align to "None" to work. > > Does this wording indicate a special dependency between these settings? The values in the GUI are a guideline. The actual start and end sectors for the partition will be set according to the alignment chosen. With a value of "None", the GUI values are used. The "None" setting is more of a legacy from older versions. I have considered removing the Align to "None" setting. > > Otherwise creation of a logical partition would fail because unallocated > > space _must_ be reserved for the EBR. > > Can these "unused areas" (traditional 63 sectors/blocks?) be smaller than 1 > MiB? Yes. I suggest you experiment with GParted and the align to "Cylinder" and "MiB" settings to see how these impact the partition alignment. > > If Align to "Cylinder" is chosen then GParted will align the partition to > > the nearest cylinder, which might be up to 8 MiB from the end of > > the previous partition. > > Does this mean that the free space around the selected partition can > eventually not be represented by an integer MiB value? Yes, if I understand your question correctly. The values set in the GUI are a guideline only. The choice of alignment will affect the actual start and end sector values for the partition. I think the key thing to realize is that when a value of "Free space preceding (MiB)" is set to 1 MiB, the actual value used might vary based upon the choice of alignment. Does that help to explain how GParted works?
(In reply to comment #12) > I have considered removing the Align to "None" setting. Please keep this configuration option. > The values set in the GUI are a guideline only. I do not like this limitation by the current graphical user interface. I would prefer to specify exact values. Would you like to use floating point values in the input fields eventually? > I think the key thing to realize is that when a value of "Free space preceding > (MiB)" is set to 1 MiB, the actual value used might vary based upon the choice > of alignment. How do you think about to avoid this variation possibility? > Does that help to explain how GParted works? Partly, yes.
(In reply to comment #13) > (In reply to comment #12) > > The values set in the GUI are a guideline only. > > I do not like this limitation by the current graphical user interface. I would > prefer to specify exact values. Would you like to use floating point values in > the input fields eventually? No. Only integer values should be used. > > I think the key thing to realize is that when a value of "Free space preceding > > (MiB)" is set to 1 MiB, the actual value used might vary based upon the choice > > of alignment. > > How do you think about to avoid this variation possibility? Since the smallest unit currently supported by GParted is 1 MiB, it does not make sense to me to change this. From reading your comments, it appears that what you really want is the ability to specify sizes in units other than MiB. As you pointed out in comment #4, there is already a bug report open for supporting sectors in the GUI. As such I am closing this report as RESOLVED - NOTABUG, because the choice of 1 MiB in the GUI to represent reserved space for partition structures (gpt, mbr, ebr), is the current design decision.
(In reply to comment #14) > Since the smallest unit currently supported by GParted is 1 MiB, it does not > make sense to me to change this. It seems that an other user like Ronald F. Guilmette has also got strong opinions (bug #695594) about involved design decisions.