Theme name: oxygen-gtk Kernel version = 3.4.1-desktop-0.rc1.1.mga3 Distribution=Mageia release 3 (Cauldron) for x86_64 CPU=Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz When using drakdisk to create new partitions it creates empty space between the new partitions. this empty space cannot be seen when using drakdisk but using other partition tools like for example gparted we can see that this unallocated space goes always around 1.86 MB. I dont know if this is on purposes but creating new partitions with other tools does not leave unallocated space between partitions.
CC: (none) => simplew8, thierry.vignaud
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?
Source RPM: (none) => drakxtools
That would be http://svnweb.mageia.org/soft?view=revision&revision=1844
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
Priority: Normal => LowSeverity: normal => enhancement
Priority: Low => NormalAssignee: bugsquad => mageiatoolsSeverity: enhancement => 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 => RESOLVEDResolution: (none) => INVALID