| Summary: | drakdisk creates unallocated space between new partitions | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Simple <simplew8> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | anssi.hannula, davidwhodgins, neoser10, nic, thierry.vignaud |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakxtools | CVE: | |
| Status comment: | |||
|
Description
Simple
2012-06-05 22:47:09 CEST
Simple
2012-06-05 22:48:04 CEST
CC:
(none) =>
simplew8, thierry.vignaud
Simple
2012-06-05 22:48:17 CEST
CC:
simplew8 =>
(none) Agreed that this should be changed. The first partition should normally start at sector 2048, as the 1mb alignment of partitions is needed for 4k sector drives, and various flash devices. By default, all partitions should be created as a multiple of 1 mb in size, minus 1 sector, to leave room for an extended partition table following that partition. Extended partitions should have the partition table in the last sector of the 1MB area used by the partition, prior to it, which which would then automatically put the extended partition on a 1MB boundary, and eliminate the waste that was cause by using a "track", as the size of the area reserved for the table. This would leave no empty space between partitions, and keep all partitions on 1MB boundaries. The only unallocated space would be in the first megabyte, between the bootloader and the first partition, and the last sector of each primary partition that isn't followed by an extended partition. As always, advanced mode should allow overriding the settings. CC:
(none) =>
davidwhodgins Ansi, a side effect of your patch :-) CC:
(none) =>
anssi.hannula In advanced mode you still cant avoid it. Thierry would it be possible to say what patch is that to revert drakdisk to allow some tests?
Manuel Hiebel
2012-10-07 11:44:36 CEST
Source RPM:
(none) =>
drakxtools Still happens in 5Beta3. New install in VM with 80GB vdi created root, swap and home. 1.11MiB between root and extended 1.44MiB between swap and home 2.62MiB after home New disk, manual creation partition 1 1.69MiB unallocated extended partition 2 1.44MiB unallocated partition 3 2.62MiB unallocated CC:
(none) =>
nic
Thierry Vignaud
2015-05-15 16:57:32 CEST
Priority:
Normal =>
Low
Samuel Verschelde
2016-10-15 20:11:08 CEST
Priority:
Low =>
Normal This is reproducible using mbr disk with MGA6 today https://drive.google.com/open?id=1BFILGeWhotqRQjGfKeKDS-GTNnXFpUXY Acronis Disk Director (Linux based partiiton editor) does not show the spacing between partitions CC:
(none) =>
neoser10 There is a problem that some hard drives falsely report to the os that they have a 512 byte physical sector size while internally using a 4KB physical sector size. Not having partitions aligned on physical sector sizes has a huge impact on write performance, as one logical 4KB write may overlap two physical sectors causing each write on the drive to have to perform two reads, a merge, and two writes (the merge is very slow on the drive's internal controller). That problem showed up around the same time ssd drives became commonly available, where the partitions must be aligned with NVM page boundaries, which can vary in size from 4KB to 16KB, and possibly other sizes. The decision was made to always align to 1MB boundaries, as all of the various sizes fit into 1MB an integer number of times. With mbr style partition tables, there's also the requirement that partitions are aligned with what ever the drive shows as a cylinder size. That's why the gap can be slightly over 1MB. While gparted is technically correct in showing the gap, it's space that is dangerous to use on a drive that falsely reports the real physical sector size, which is why tools such as diskdrake and Acronis have chosen not to show those gaps. Otherwise diskdrake would need an accurate and up-to-date list of which drives report 512 byte physical sector sizes while internally using 4KB sector sizes, with the risk that newer drives would be missing from that list. Closing the bug as invalid, as it's working as intended. Status:
NEW =>
RESOLVED |