0
I'm building my very first UEFI based server. I am manually arranging the gpt based partitions on the hard drive. I am placing the EFI system partition as the very first partition. Usually I will create a 127mb dummy partition as the very first partition to do a universal alignment (or I will create the first partition to end on sector# 262143 which will align the following partition(s) for any configuration (cluster size, raid stripes, etc)). I suppose I can be a little conservative about utilizing all possible drive space, so I was wondering: If I use this "dummy partition" as the location for the EFI system partition will it cause some kind of major performance issue? (since its a 512e drive and the partition will not be aligned) I tend to think not, since the partition is basically read one time during the boot process and not used to write files on a regular basis. But I just wanted to throw that question out there, just to be certain that I'm not doing something completely ridiculous. So is it ok to set the EFI system partition up as the first partition (unaligned) on a gpt hard drive and at the same time use it as an "offset" to align the following partitions? Thanks in advance and best regards.
Thanks, I do always use the divide by 8 to double check that everything is aligned, its nice to hear someone confirm it. I always leave 16mb between partitions, I tell myself its in case I need to resize, etc. I also leave an odd leftover amount at the end and recently learned that is good for gpt because of the 2nd copy of the partition table isn't universally recognized and can cause issues of some kind if there is a collision. I plan to use Server 2016 (hyper-v's) and possibly if I can swing it clonezilla for creating backup images. Using the whole process to catch up on partition info. – Johnny The Critic – 2017-07-08T00:47:14.783
Oh, btw, I checked and it seems that Gparted isn't going to allow me to do the EFI partition at the first available sector (40?)... It placed the start right at 2048, I may have to boot with DOS fdisk or something to see if somehow I can do it or just leave it well enough alone. Its the first time I ever ran into an over-efficient partitioning utility situation. – Johnny The Critic – 2017-07-08T00:50:27.847
@JohnnyTheCritic; I personally use
gdisk
in Linux orgpt
on a Mac. GParted is probably in MBR compatibility mode and that's why it won't let you go below 2048. You might be able to turn that off but I don't use GParted so I can't say. But DOS fdisk definitely won't give you the control you're seeking here. – Wes Sayeed – 2017-07-08T00:57:02.970In terms of data structures, given a default-sized partition table and 512-byte (logical) sectors, the first usable sector on a disk is 34, not 40; but 40 is the first that's properly aligned for a disk with 4096-byte physical sectors. Most tools these days enforce 1 MiB (2048-sector) alignment by default. There are sometimes ways around this. In
gdisk
, you'd typex
and thenl
(lowercase "L") to change the alignment value, thenm
to return to the main menu. GParted doesn't allow enough precision to do what you want, AFAIK. – Rod Smith – 2017-07-11T12:25:42.997One more point: I recommend making the ESP 550 MiB. The reason is twofold: Some tools (like
mkdosfs
in Linux) will create FAT16, rather than FAT32, on partitions smaller than 500-something MiB. The cutoff value is something weird, at least formkdosfs
, so I round up. The problem with FAT16 is that some (mostly older) EFIs have flaky FAT drivers that don't handle FAT16 very well, resulting in files that seem to disappear. Likewise, some ESPs have flaky FAT drivers that don't handle FAT32 partitions smaller than 512 MiB. Thus, making the ESP 550 MiB is safe. – Rod Smith – 2017-07-11T12:29:21.563