NetApp support has suggested us to align partitions to improve I/O performance, in short: starting sector must be divisible by 8. How can I move the starting point in a misaligned partition -in production, with ext3- under Linux?
A screenshot with a misaligned (start=63s) and aligned (start=64s) partition is available at:
(If anyone is interested in this topic, NetApp has a good document explaining performance issues in misaligned partitions, search for "tr-3747": Best Practices for File System Alignment in Virtual Environments.)
I have tried using parted with "resize + move" commands, but when moving the starting point I get this error:
(parted) resize
Partition number? 1
Start? [64s]?
End? [419425019s]? 419425018
(parted) move
Partition number? 1
Start? 65
End? [419425019s]? 419425019
Error: Can't move a partition onto itself. Try using resize, perhaps?
Using fdisk's 'b' command in expert mode ('move beginning of data in a partition') works, but it doesn't move the file system.. thanks!!
You have two options: move all the misaligned VMs into a datastore created specifically for that misalignment, or fix all the VMs.
If you decide to fix the VMs, my understanding is that you will need to reboot the servers. Here's a Netapp link you can start research on if you decide to take an outage. mbrscan and mbralign are the tools needed.
If you can't take an outage yet and decide to create a new datastore, you'll need to read this. You will end up with a separate LUN for every type of offset, but you can take your time and schedule outages for realignment when it's less disruptive. Remember, once you put a live VM into a specially offset LUN, you can't VMotion it around until you fix it, unless you're willing to live with the bad performance.
I'm not aware of a solution that does this on-the-fly or even without downtime. I think your best and only chance is to backup the root-fs (or better, the whole system) and create new aligned partitions.
fdisk manipulates the MBR, which is 512 bytes of data at the beginning of the disk. It will not manipulate the rest of the data. You will need to bring the host down, provision new, properly aligned storage, and then use
dd
or similar to mirror the old partition into the new partition (on the new storage).This type of thing cannot really be done without downtime, as the filesystem generally depends on knowing where the first (and last) block resides, relative to the partition. Obviously, you can't truncate your partition (which is what fdisk would do) and moving the entire system +1 block while running would have... well, I'm not aware of any filesystem can could properly handle that situation.