For some reason, the first partition of my VPS (running Debian 8) is aligned to sector 63 (instead of 2048)

Model: VMware Virtual disk (scsi)
Disk /dev/sda: 314572800s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start      End         Size        Type     File system     Flags
 1      63s        79971569s   79971507s   primary  ext4            boot
 2      79971570s  83875364s   3903795s    primary  linux-swap(v1)
        83875365s  314572799s  230697435s           Free Space

Now I want to resize the partitions to allocate the free space, unfortunately fdisk starts the first sector at 2048. But as I've read here it is possible to force fdisk to start at 63 using this command.

fdisk -c=dos -u=cylinders /dev/sda

How safe is this? Moreover, as this method is deprecated does this harms the performance of my VPS?

  • The further reading at unix.stackexchange.com/a/464822/5132 might help answerers here. – JdeBP Aug 31 '18 at 7:42
  • Your swap partition isn't aligned either (not MiB-aligned and not even 4K-aligned). And they're even both misaligned in different ways, so even if the host did a off-by-one to support virtualizing some old never-change-a-running misaligned system, it still wouldn't fit. – frostschutz Sep 1 '18 at 7:31

When extending the size, as it involves deleting the partition, you will have to recreate it again at whatever number it starts.

otherwise it won't be recognized at best, and at worst there can be data corruption.

If that VPS is a template for creating other VMs, I would take the trouble to recreate/move the beginning *and * the data/sectors to sector 2048.

As it is a VM, if you do want to move the partition, I would not exactly move it, I would create a partition on the side, copy the data and boot with the copy partition. That is the beauty of working with virtual machines, you have more room to test things.

PS. As for my strictly personal opinion, the small gain on performance does not make it worth moving it from sector 63. I would wait for the machine to become retired, it will happen sooner or later.

As for partitions alignment:

You want to leave the partition aligned to the 4096 byte boundary. On that way real sectors are mostly certain to be aligned with virtual sectors and VMWare will your hypervisor/VM will extract a better performance from the hardware.

For understanding why unaligned partitions are a performance problem, see this image from purestorage.com:


Consulting the white papers of a storage specialist in the industry to have a better idea what are the current best pratices:

Modern vendor-supported operating systems (OS) from Microsoft and Linux distributors such as Red Hat no longer require adjustments to align the file system partition with the blocks of the underlying storage system in a virtual environment.

(.e.g. "leave the default settings alone")

However to continue replying to the original question, visiting a couple of linked white papers:

Aligning your partitions to a 4K boundary in both the VMDK and the LUN is a recommended best practice

And also:

In the output for each device, multiply the start by sector size (normally 512 in the fdisk output), and then divide it by 4096. If the result is an integer (whole number), it is ALIGNED, if not, it is MISALIGNED.

So, checking your question about creating a partition at sector 63:

512 * 63 / 4096 = 7.875 => MISALIGNED

I would probably use and leave the default in the future at 2048. Let's check it:

512 * 2048 / 4096 = 156 => ALIGNED


FAQ: Guest VM file system partition/disk alignment for VMware vSphere, other virtual environments, and NetApp storage systems

How to correct guest VM data partition alignment in a VMware vSphere 5.x environment

How to align blocks in VMWare ESX

  • Thanks. So if I want to extend the first partition with the free space, I should align the (new) first partition to sector 63 using fdisk -c=dos /dev/sda? – wouter205 Sep 3 '18 at 8:17
  • @wouter205 If you recreating it, you must point to the true beginning of it, now way around it without doing more complex operations to move the sectors. – Rui F Ribeiro Sep 3 '18 at 9:04
  • Thanks, that's what I thought. I'll give it a try when the server is not busy later this week. – wouter205 Sep 3 '18 at 9:25
  • 1
    I've extended the partition today usding ´fdisk /dev/sda -c=dos´ and everything worked as expected. A complete outline of the commands can be read at askubuntu.com/a/1072988/24931 – wouter205 Sep 7 '18 at 7:41
  • @wouter205 Congrats. It is not a difficult operation once it is done, right? – Rui F Ribeiro Sep 7 '18 at 9:03

For reference:

  • Sector 2048 on a conventional 512b sector drive is the first sector after the 1MB mark.
  • Sector 63 is the sector right before the 32k mark, and originally corresponded to the last sector of the first track on the first platter of most hard disks (at least, once disk geometry became reasonably standardized).

So, why are these relevant at all?

There are a couple of reasons that you don't conventionally start partitions at sector 1:

  • It leaves space for the bootloader. The MBR format only leaves a little over 40 bytes for the bootloader. That may have been enough back in the CP/M and DOS days, but it quickly became too small. So, the convention became that you left the (almost entire) first track of the first platter for the bootloader. GRUB for example actually requires this when used on an MBR partitioned disk.
  • It's also significant when dealing with disks partitioned multiple ways. Some partition table formats don't start at sector 0. A modern example of this is GPT, which starts at sector 1, and conventionally goes all the way up to sector 31. A much older example is the partition table format used by Apple systems with the classic OS. This is a much more niche usage, but it's still at least somewhat relevant because of GPT.
  • Aligning your partitions so that they start and end on natural boundaries of the hard drive's geometry (such as cylinder or track boundaries) improves performance. Sector 63 happens to be right at a natural boundary, and most filesystems don't actually touch their first sector very often (if at all), so it ends up placing the second sector at the start of a new cylinder, and usually also at the start of a new track, which is usually accessed very frequently in certain older filesystems (though not at all in some others, ext4 and BTRFS for example will generally never touch it).

Because of points 1 and 3, sector 63 ended up becoming the standard. However, it's largely fallen out of use for reasons I will outline below.

OK, so why did it get increased to 1MB?

This one is a bit trickier. I've not seen any actual definitive historically referenced answer as to why 1MB was chosen, or even when exactly this started being the norm. IT has some advantages though:

  • It happens to be properly aligned for both 512b and 4k sector sizes, unlike starting at sector 63, which will usually result in most of your files in the filesystem itself being unaligned (this wasn't an issue originally with FAT12 and FAT16, as they usually defaulted to operating with 512b sectors internally).
  • A lot of networked storage protocols define 1MB as the maximum block size for reads and writes. By aligning partitions like this, you end up aligned properly with thes block protocols, and thus avoid the possibility of having to do RMW cycles when you only want to do a partial write.
  • Most modern SSD's present as having 512b or 4k sectors, but they actually operate internally with much larger blocks. Usually these are 2MB or 4MB blocks these days, but a lot of older ones used 1MB blocks. Aligning properly with these blocks actually significantly improves the life expectancy for some SSD's, and also improves write performance significantly.

OK, but what about the original question?

Given the above, moving to 2048 as the base should actually improve the performance a little bit for your VM.

It should also be perfectly safe, just make sure you reinstall the bootloader after the move, as it may be referencing exact block locations within the filesystem instead of files, which won't point to the correct locations after the move.

  • Thanks for the information. If I decide to move to 2048 as a base, how can I reinstall the bootloader as this is a remote server thus I cannot boot it from a live image to reinstall grub. – wouter205 Sep 3 '18 at 7:08
  • If you can't boot a live environment, then how exactly do you plan to move the root partition? Because it's either do it offline from a live environment, or do some really complex and potentially very risky stuff from single user mode that would not prevent you from reinstalling the bootloader. – Austin Hemmelgarn Sep 4 '18 at 14:37
  • I won't move the root. I'm going to recreate the partition table in order to use the unallocated space at the end of the disk. I will let it start from sector 63, needed to be able to boot. – wouter205 Sep 5 '18 at 11:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.