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, 2018 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. Sep 1, 2018 at 7:31

3 Answers 3


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, 2018 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. Sep 3, 2018 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, 2018 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, 2018 at 7:41
  • @wouter205 Congrats. It is not a difficult operation once it is done, right? Sep 7, 2018 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, 2018 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. Sep 4, 2018 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, 2018 at 11:50
  • If you partition your disks with fdisk, the start sector will be 2048+.
  • If you use cfdisk, which probably happens when you add a disk later on, after the initial install, the start sector can be 63.

So if you have a disk with start sector 63 and you want to resize the partition, then just use cfdisk instead of fdisk.

I ran into this issue when adding and re-sizing virtual disks in ProxMox. Basically if I had to change something on /dev/sda* I would use fdisk and if I needed to resize partitions on /dev/sdb|c|d etc, then I'd be using cfdisk. Learned that the hard way.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .