A small amount of space is needed at the beginning of the drive before the first “real” partition for this.

GPT also wants to store a backup copy of the partition table at the end of the drive, again small amount of space after last partition required for this.

It is possible but not recommended to use block-lists to load Grub. Even where this works you still need to make space for the the backup partition table at the end of the drive.

However if something goes wrong it is possible to delete the GPT partition table and recreate a standard one without losing data, as long as you use the same start and end values for the partitions.

I doubt that Palimpsest deals with all that but feel free to try it for yourself and correct me if you are left with a machine that actually boots!

It doesn’t matter whether you are using native “BIOS” support or Grub to do the work for you the fact is it can be done and so what I said is true.

And to correct you even further it isn’t called an MSDOS partition the correct terminology is “BIOS Boot Partition” type “EF02″, look it up.

http://grub.enbug.org/BIOS_Boot_Partition

But your assertion is not quite true either. Yes, you can use GPT but you still, even in your article, use an MSDOS partition. As far as the BIOS is concerned you’ve booted off an MSDOS partition. It’s Grub that “bridges” to the GPT partitions.

On a system that truly supported GPT (Apples and Itaniums, for instance) you wouldn’t need the little MSDOS partition.

The problem has been around for while:
http://forum.synology.com/enu/viewtopic.php?f=124&t=11653

But is still an issue:
http://www.mail-archive.com/debian-user@lists.debian.org/msg587732.html

Their proposed solution is to run a DOS utility and/or have us modify our OS:
http://wdc.custhelp.com/app/answers/detail/a_id/5357

WD’s own admission of lack of Linux support:
http://wdc.custhelp.com/app/answers/detail/a_id/987/related/1

I’d suggest the author looks at http://www.rodsbooks.com/gdisk/whatsgpt.html and an article I wrote after I had upgraded my own laptop to GPT http://johnlewis.ie/converting-to-gpt-in-ubuntu/

In response to the previous commenter, your third point is on shaky ground. Linux is ready for 4k sectors (at least Ubuntu is, and I’m willing to bet most others too). Since 10.04 the partitioner in the installer defaults to a 2048 sector alignment. See https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Partition alignment changes may break some systems.

I also wrote an article on why partition/sector alignment isn’t nearly as big an issue as it once was http://johnlewis.ie/partition-alignment-largely-a-moot-point-now/

I don’t know who’s checking these articles over but this one needed to be better researched and more accurate. I hope you do better in future.

so yeah: the most conservative approach is probably to stay a step back from the current highest-density, and to stick to 1-platter disks. IMO this is a bit silly, though, because disks are so cheap we really need to regard them more as consumables (plan <= 3 years use).

It implies that LBA is the reason partitions are limited to 2.199TB. The fault lies with MBR partition tables, not LBA itself. GPT fixes this problem (mentioned far enough into the article that you disassociate the two).

It also doesn’t discuss the various types of Advanced Format drives, the most common of which expose 512-bytes to the OS. Little of Act II describes “real-world” hardware! Certainly not the 3 TB disk from Western Digital the author bought.

It also ignores the sector alignment problem, which is the most important issue/problem with 4K (and larger) sector disks. The sector alignment issues with Linux are the real reason Linux (the community and distributions, not the kernel) is not ready for 4 KB sector disks.

I expand on all of this on my blog: Comments on “3 TB disks are Here” from Linux Magazine. I intend on having more posts about working with GPT soon so you can mitigate all these problems.

The linked article says that “(hard) drive sizes are typically given in terms of total storage capacity, where 1 byte = 10 bits… This invisible (to the end-user) additional capacity is used to store positional information and for error correction code.” In other words one can estimate that for every N bytes of storage capacity visible to the user an additional 2N bits of total platter capacity are required.

However, when one is talking about a M byte sector with N extra bytes, then 1 byte is equal to 8 bits (as it is in the rest of the world). The 40 bits used for ECC is 5 bytes and not 4 bytes.

As luck would have it, one need not calculate bits. The article should read that a 512 byte sectors requires an additional 40 bytes for ECC and not 40 bits (a mistake which was also made in the linked article). Similarly, 512 byte sectors require an additional 320 bytes for ECC and 4K byte sectors require an additional 100 bytes for ECC. To note, 220 bytes of 4K is in the order of the quoted 5.5% additional capacity.

There’s an error regarding physical bit density on the platters

It areal density (as in area)

http://www.pcguide.com/ref/hdd/op/mediaDensity-c.html

Rather than aural density, aural refers to sound

I have heard that HD with capacity > 1 TB are very prone to failure. Is it a myth? If it is somehow true, can you please elaborate the technical reason? Thank you very much in advance.