Aligning disk partitions to prevent SSD wear

oxfordguy said:

Okay.

BTW I'm thinking of creating a 60Gb bootcamp partition for Windows 7 Ultimate 64 bit to run a couple of games (e.g. the upcoming Skyrim), is there anything I need to be aware of when creating this to keep my partitions aligned? Thanks

Click to expand...

Anyone? Would really like to setup a Bootcamp partition, but want to make sure my SSD stays aligned.

As a reminder, current setup is:


If I want a 60Gb-ish Bootcamp partition, what's the best way to go about this? Thanks

Are there any guides which explain how to set up SSDs clearly. Here's my partition setup, does it look OK?


Disk /dev/disk0: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1B301FCD-D9B8-43D1-A4DF-6C83F102D171
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 262165 sectors (128.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 488798207 232.9 GiB AF00 Snow Leopard
3 489060352 976773119 232.6 GiB 0700 EXTRA

Bringing this thread back to life in Jan 2013. There's still talk about aligning SSDs, but all the expert discussions seem to date to 2010 / 2011.

Is aligning partitions in SSDs still relevant? Is it still a good thing to do? I am about to upgrade to an SSD so if I'm gonna align it then soon would be good.

You don't need to manually align your partitions, Apple's Disk Utility does all that you really need it to do.

Disk utility automatically aligns partitions, to a degree. It doesn't do anything in the way of NAND page size or NAND erase size. It's not an issue. What does matter is File Allocation Unit Size. You can confirm that it does indeed align the partitions. All you need is a utility called gdisk (GPT fdisk).

Open a shell window and execute gdisk:


X is the number disk you want to check. This information is available using Disk Utility or the command-line utility called diskutil (diskutil list).

You should get something like at the bottom Get the number under start for the largest partition. Multiply this by the Logical Sector size, which should be 512 bytes for most SSDs. Don't worry if yours isn't though. Now you have the partition offset in bytes.

Now you have to divide the partition offset by the file allocation size. With all modern SSDs, the File Allocation Unit Size is 4096 bytes. The number that gdisk reports is a number of sectors, not bytes. Multiply the number of sectors by the Logical sector size and then divide the result by 4096. If its an integer, then the disk is aligned.

Disk Utility partitions drives (I don't know about HDDs, I only use SSDs) like the output below. And I can vouch for this alignment because I have been using it for about a year now on my MacBook Air. I programmed on this MacBook Air (i.e. small writes) and I managed large video files on it. I also have this same alignment on both of my MacBook Pro's 256GB Crucial M4s since thanksgiving of 2011, and my hackintosh's 3 SSDs (OCZ Vertex 4 128GB, OWC Mercury 3G 120GB, and a Samsung 840 Pro 128GB (its a very sexy drive xD) for about a month. All of those SSDs were formatted as HFS+.

For those who are wondering, I have a MacBook Air with a factory partitioned 256GB SSD, and this is what my gdisk output looks like:


And if you ever stress out, remember, its just another hard drive... Oh and make your backups

natesymer said:

<Lots of useful stuff.>

Click to expand...

Hi Nate, big thanks for your useful response. I tried out the gdisk command - you missed out saying that once it's running, you need to type 'p' to get the partition table listing. Here's mine:

As you can see, partition 1 and 2 start on the same offsets as yours, and this is the case for every modern mac I've looked at.

What I'm hearing however, is that as well as the partitions being aligned, the SECTOR OFFSET also needs to be aligned. I'm stumbling my way through this topic, but the general gist (the numbers appear different to me every time I look at it) is that SSDs have 4kb page sizes, and that the first offset should also be a multiple of 4kb from the start of the SSD. (in the tables above, the first offset is Partition 1 starting at sector 40)

Why? Because the filesystem measures offset starting from the start of the sector. (possibly only from the start of the first sector, not from any other sector).

So if the first sector has the wrong offset, then even though the filesystem is still aligned on 512byte boundaries, the OS is not saving files to neatly fit into the SSD 4kb page size. Some files are overlapping on pages when they could neatly fit into one page.

Realigning on page size is meant to have a small but measureable effect on random r/w. The last test I saw of this was a year or two ago, and gave a 50mb/s increase. (Fun to have for tweakers like us but not a big deal for normal people )

I was wiping and reinstalling a Macbook Pro HDD the other day and for *fun* I tested a custom offset, theoretically aligned on page boundaries:

Sector 1 (EFI) Start at 4096 sectors (not Disk Utility's 40 sector offset)
Sector 2 (Main) Start at 409600 sectors (not 409640)

Result: Failure. OSX started to install then refused to continue halfway though. Disk Utility said EFI was too small, claimed to repair it, but actually failed to repair it. I wiped and restarted with standard DU offsets which went fine.

I need to recalculate these offsets to give the right size EFI partition while staying on page boundaries. (A too big EFI partiton might be OK but I don't know how sensitive the installer is). But I haven't really got the time or the knowledge to do so. If you can suggest some numbers I'll try again maybe in a couple of weeks as I have another disk wipe coming up soon.

Hello RedTomato,

I have tried using an EFI partition of 199 MB (start sector=2048, ending=409599). I had no problems booting up and running OS X with this EFI partition size, but, in hindsight, it is probably because I restored my OS X installation from a backup rather than re-installing anew. It appears from your experience that fresh installation won't work with an EFI less than 200 MB.
It's also likely that firmware updates will fail as they too may be sensitive to EFI size.

What I decided to do instead was create an EFI that was 200 MB. And now.....some numbers:

Start sector=2048 and ending sector=411647. This places the OS X system partition on a start sector of 411648.

EFI start sector 2048 and OS X start sector 411648 are both, when converted into bytes, divisible by 512K erase block (524288 bytes), 4K page size (4096 bytes), 8K page size (8192 bytes).

IF you like, you can still begin your EFI at sector 4096. What I did was delete my OS X system partition first. This created the free space needed to move the EFI further along. Then I deleted and recreated the EFI at the new start sector. Once EFI is in place, simply recreate a 'mac os extended, journaled' partition in the free space immediately following your EFI. That places the system partition's beginning sector (offset) on the first sector following the last sector of EFI. Next, you would restore your OS X partition from your backup. Job done.
I don't know which tool(s) you are using to do all of this. iPartition, perhaps? I used Gparted to fix the EFI, and Apple Disk Utility to remove, then remake the OS X system partition.

Does all this mean that the partitions are aligned? I hope so.

I've experimented with iPartition today. It's a nice application, I must say. One thing I noticed about removing and recreating the EFI partition within an OS X environment is that the partition #'s (BSD names?) are reassigned. IF you start out with EFI as disk0s1 and your system partition as disk0s2, then removing EFI will result in the second partition being rebranded disk0s1. And there is no changing that once it's done. The new EFI will become s2.

When verifying the disk in Disk Utility, and error will come up complaining the the Target volume cannot be found. Will it still boot anyway? I don't know. I did not try. I prefer that Disk Utility approve of my work, so I ended up wiping the entire disk and starting over, creating EFI, then OS X partition, then restoring.

Performing these tasks in a Linux environment does not reorder the partition numbers.

This renumbering may not be an issue for most. Removing your existing EFI and retaining your OS X partition might be an unusual way to do this, but I did not need to move the OS X partition as it was already aligned. I was merely testing iPartition to see how it worked.

Studio K said:

I've experimented with iPartition today. It's a nice application, I must say. One thing I noticed about removing and recreating the EFI partition within an OS X environment is that the partition #'s (BSD names?) are reassigned. IF you start out with EFI as disk0s1 and your system partition as disk0s2, then removing EFI will result in the second partition being rebranded disk0s1. And there is no changing that once it's done. The new EFI will become s2.

When verifying the disk in Disk Utility, and error will come up complaining the the Target volume cannot be found. Will it still boot anyway? I don't know. I did not try. I prefer that Disk Utility approve of my work, so I ended up wiping the entire disk and starting over, creating EFI, then OS X partition, then restoring.

Performing these tasks in a Linux environment does not reorder the partition numbers.

This renumbering may not be an issue for most. Removing your existing EFI and retaining your OS X partition might be an unusual way to do this, but I did not need to move the OS X partition as it was already aligned. I was merely testing iPartition to see how it worked.

Click to expand...

Hi StudioK,

Thanks for your feedback on iPartition. Yes, it's what I used to move my partitions. That disk renumbering might be a showstopper. What I did, which might have kept the same numbering: I erased the entire OS drive, then recreated the three partitions, manually setting the offsets and partition types. (I copied the offset for the recovery partion from the standard install). I didn't get any warnings in Disk Utility about not being able to find the target, but I will check the numbering next time I do it. If it is a problem then I'll have to grab a linux tool / liveboot environment. Not played with linux for a very long time...

StudioK, also big thanks for giving me a new set of offset numbers to try out. Really, what we need to do is:

- first benchmark OSX on your SSD as set up by the standard Disk Utility/ ML installer
- then reinstall with custom partition offset, and benchmark again.

Is there a difference? Especially in random r/w but maybe in other areas? If there's no difference, then there's no point in doing all this rubbish