SSD: MBR versus GPT

XZS · 2011-06-04 11:42:14

I want to partition a new SSD for use as the only drive for a Laptop. Now I wonder wether to use GPT or MBR. The wiki article states that GPT shall be used. But GPT adds significantly more overhead, as it includes MBR completely. Additionally, I suspect compatibility issues. The only advantage I recognize is the huge amount of partitions, which I will not need with only a root and a /boot-partition. Are there any more arguments for GPT, especially on a SSD, or won't it hurt to just stay with the old MBR?

Last edited by XZS (2011-06-04 11:43:54)

KimTjik · 2011-06-04 12:22:56

Do you have any reference about GPT adding "significantly more overhead"? Sure, it's not a straightforward when used on BIOS based systems, and depending on bootloader it could be necessary to add a small extra partition. I've not noticed any performance issues, but am interested in whatever information you have.

I suppose the best argument on BIOS systems is that GPT gets alignements right without a lot fiddling.

R00KIE · 2011-06-04 13:15:30

I would be concerned with compatibility issues first. GPT is just an updated and improved way of storing information about partitions, there should be no performance decrease or increase. With either scheme you'll have to align all partitions so it works optimally with the SSD you have, I'm not so sure just using gpt will get the alignment right, the data structures of the filesystem have to be taken into account and what matters is where and how the actual data inside the filesystem gets written. This depends on the flash chips used on the SSD and as far as I know manufacturers don't state the block size that should be used for best alignment.

Given the current sizes and prices of SSDs I doubt any common partitioning scheme would exhaust the allowed number of partitions for an mbr style system, on top of that there are a lot more utilities supporting mbr than gpt so if anything goes wrong you'll probably be better off with an mbr scheme (nothing is better than regular backups but we all know how it goes with regular backups ).

graysky · 2011-06-04 13:48:02

R00KIE wrote:

I'm not so sure just using gpt will get the alignment right

gdisk (renamed gtpdisk I think) does the alignment.

R00KIE · 2011-06-04 21:13:11

graysky wrote:

R00KIE wrote:
I'm not so sure just using gpt will get the alignment right
gdisk (renamed gtpdisk I think) does the alignment.

And is that alignment for the start of the partition or does it take into account all the data structures that come before the actual data that is written inside the partition? People use all kinds of different filesystems and I'd say that some if not most were implemented before SSDs and advanced format drives therefore some assumptions about sector size might be built-in/hardcoded, to make matters worse a sector size of 512 bytes is reported for compatibility which screws everything when the real/optimum sector size is much larger.

I've seen it explained somewhere with a great detail how to align one specific filesystem (I can't find it now), and a fairly good knowledge of the inwards of the filesystem _and_ the sector size was needed in order to use some "tweaked" parameters when formating the filesystem and aligning the partitions so the actual data that is written falls inside the real/optimum sector boundary.

So far I didn't have to deal with alignment in a serious way but from what I have seen it seems there is more to it than just using tool xyz to get the partitions' start aligned and expect to get the most out of a specific drive, if that is the case parted (or gparted) will do the job just fine (as will cfdisk if invoked with the right flag I believe).

KimTjik · 2011-06-04 22:36:22

ROOKIE, unfortunately yes it's a guessing game sometimes to get confirmed information about SSD drives. I actually don't understand the point of this, as if the user should be kept in the dark from how to optimize the use a bought product.

Still it looks a lot easier to use tools for GPT since you at least get a better starting point without quirks. Beyond that I don't have enough knowledge, but I rather prefer a clean setup of partitions not fully optimized, than I quirky one not fully optimized. When a new updated and stable install media is ready I expect the use of GRUB2 or syslinux to become easier as well. Furthermore many of the motherboard releases this year will be shipped with UEFI (it solves some problems, but I would rather have seen a cleaner implementation than UEFI), which will promote such a switch.

XZS · 2011-06-04 22:50:01

I hold myself for sufficiently educated to correctly compute some alignments even with old fdisk. Tuning of filesystems (most likely ext4) could be more difficult. So I would really like to read the article R00KIE mentioned.

R00KIE wrote:

I've seen it explained somewhere with a great detail how to align one specific filesystem

KimTjik wrote:

Do you have any reference about GPT adding "significantly more overhead"?

For simplicity, let's read Wikipedia about it. There we can learn that GPT adds at least two headers, which have the same size as the MBR header. Plus the original MBR, that it includes, it is at least three times as big. I know that this is not much on a 120GB device. But if it does not provide me some fancy features, I can consider it wasted.

How do I determine wether I have an UEFI or classical BIOS?

graysky · 2011-06-04 23:05:29

I believe part of that is a redundant backup of the partition table... that is your friend.

Last edited by graysky (2011-06-04 23:05:40)

R00KIE · 2011-06-05 02:36:15

I have been trying to find the article I've mentioned and no luck ... I'm starting to think I've dreamed about reading it
If I really did read it and if I remember it correctly, the example was about aligning some FAT* partition and the author said what was inside the partition, where and how much space it used and which things should be tweaked so the data zone would be sector aligned.

Regarding ext* filesystems I couldn't find much more than aligning the partitions and maybe specifying stride and stripe-width when using mkfs [1].
I also found the article written by Theodore Ts'o [2] which was already mentioned in the wiki. I also found this [3] but it has no replies, still it might be worth checking after formating the partitions since everything would probably have an offset and make everything unaligned.

[1] http://www.nuclex.org/blog/personal/80- … d-on-linux
[2] http://ldn.linuxfoundation.org/blog-ent … block-size
[3] http://linux.derkeiler.com/Mailing-List … 01991.html

XZS · 2011-06-05 10:00:26

Thanks for the links. They tell me that alignment in ext4 is not that important when there is no RAID or other complicated orchestra of disks. A block size equal to the EBS would be nice, but not usable as it sets the minimal filesize. Though, the filesystem block size shuld divide the EBS of the disk to prevent blocks from spanning over multiple disk blocks. This should normally be the case even with the smallest possible value of 1024. So mkfs.ext4 -b 1024 /dev/sdXX shall suffice. The default for -b normally is already 4096.

graysky wrote:

I believe part of that is a redundant backup of the partition table... that is your friend.

It is. But this is also possible to achive with MBR through dd if=/dev/hda of="some cool and dry place" bs=512 count=1.
Using MBR, the first partition must start at the second cylinder which is already wasting space big enough to fit the GPT header in it. So I recognize that MBR will in fact not save any precious Bytes.

R00KIE · 2011-06-05 13:29:08

I don't know how old this info [1] is and if it applies every time, but it seems that if drives report some sensible values then things will work well. Still some tweaking might be needed to take into account the erase block size.

Manufacturers should really get their act together and start making life easy for the people writing the disk utilities/OSes and for the ones that do care and want to get things right.

[1] http://people.redhat.com/msnitzer/docs/io-limits.txt

graysky · 2011-06-05 13:43:22

XZS - in theory you can keep a manual backup of the thing and keep it in "some cool and dry place" but for those of us with multiple HDDs on multiple systems, this represents a very non-KISS approach GPT is the future, embrace it.

stqn · 2011-06-06 10:03:39

GPT doesn't seem to bring anything really useful indeed, except the welcome loss of "extended/secondary partitions", but it doesn't matter if you're not going to have more than 4 partitions, and Linux can be installed on secondary partitions anyway (unlike Windows.) I wouldn't bother with it and risk having problems with tools or OSes that don't support it later. (Ok, to be honest, I actually used GPT recently on one of my external drives, just to experiment...)

Regarding alignment, GParted aligns MBR partitions to 1MiB already.

Edit: I forgot that Mac OS X actually requires a GPT, at least if you want to use the official installer.

Last edited by stqn (2011-06-08 14:10:43)

Arch Linux

#1 2011-06-04 11:42:14

SSD: MBR versus GPT

#2 2011-06-04 12:22:56

Re: SSD: MBR versus GPT

#3 2011-06-04 13:15:30

Re: SSD: MBR versus GPT

#4 2011-06-04 13:48:02

Re: SSD: MBR versus GPT

#5 2011-06-04 21:13:11

Re: SSD: MBR versus GPT

#6 2011-06-04 22:36:22

Re: SSD: MBR versus GPT

#7 2011-06-04 22:50:01

Re: SSD: MBR versus GPT

#8 2011-06-04 23:05:29

Re: SSD: MBR versus GPT

#9 2011-06-05 02:36:15

Re: SSD: MBR versus GPT

#10 2011-06-05 10:00:26

Re: SSD: MBR versus GPT

#11 2011-06-05 13:29:08

Re: SSD: MBR versus GPT

#12 2011-06-05 13:43:22

Re: SSD: MBR versus GPT

#13 2011-06-06 10:03:39

Re: SSD: MBR versus GPT

Board footer