On 10/28/14 12:13, Bruce Dubbs wrote:
dE wrote:
On 10/28/14 00:37, Felix Miata wrote:
dE composed on 2014-10-28 00:13 (UTC+0530):
I was learning about GPT when I noticed this behavior of fdisk which I
never though about before.
Regardless of the partition table, fdisk always starts the first
partition at 2048. In reality, the maximum size required by the gap
between MBR and the 1st partition is a single sector, which's used by
GRUB 1.5. GPT doesn't need this space at all.
Then extended partitions too have a gap of 2048 sectors.
Why this behavior?
http://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/
may provide some insight WRT performance issues ensuing from other
start
sector selections.
But that works even with multiples of 8. So we can start from sector 8
in MBR and 40 in GPT.
Also I'm pretty sure fdisk uses 2048 even with -b 4096, but
unfortunately I get --
*** Error in `fdisk': malloc(): memory corruption: 0x0000000002507330
***
with that switch.
You seem to be overly concerned about the disk space below sector
2048. That's a little less than 1M -- less than a floppy disk. In the
era of $100/TB, does 1M matter?
When formatting a drive, there are several issues to consider. If
it's a boot drive, then the boot loader needs to go somewhere. Grub
puts it in sectors 2-63 for MSDOS style partition tables and in a
separate Grub partition for GPT formatted drives.
Larger hard drives (2T+) require a GPT to access the entire drive.
They also are formatted internally as 4K sectors. Creating a partition
that is not aligned with the disk architecture is inefficient.
IMO, all partitions should be aligned on 1MiB boundaries by default
for either type of partition. It's just easier to understand.
-- Bruce
But if fdisk puts it at sector 8 for MBR and sector 40 for GPT, it'll
solve the purpose.
2048 is Windows behavior ported to utils-linux. It's pointless.
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
