Partitioning a 2tb drive

Question

Im new to linux Im planning to install Squeeze on a 2tb hard drive a follows:

• / - 10gb
• swap
• remaining space will contain /home, around 1.9tb i hope, i will try to use as lvm to add my old 1tb drive later

My question is: do i have to use GPT? or MBR will be just fine

if GPT needed this scheme is good?

• /boot - 150mb
• / - 10gb
• swap
• /home (lvm with remaining space)

motherboard is an ASRock G41 btw wich i think doesnt support EFI

Answer 1

GPT or MBR?

As @mgorven said, either will work on 2TB. I've deployed dozens of MBR disk labels on 2T disks and it works fine on them. It's really your choice. I go with MBR by preference for now, but this is about to change.

UEFI and GPT

You don't need UEFI to write a GPT disk label to a disk, and if you're clever, you could conceivably boot a disk with a GPT disk label from a non-UEFI ROM (pinch of salt required; I haven't done this). The Wikipedia article on GPT has some indirect info on this.

Zones

This is often ignored by people, but it does play a role, and a potentially huge one. It's not an issue on non-spinning mass storage, but has been an issue with disks for many years. For reasons that have to do with geometry and physics, disk throughput is highest near the beginning of the disk. Throughput is broken down in zones, with speed dropping as you move from one zone to another. This implies that you should keep the most speed-hungry partitions near the beginning of the disk. This difference is quite pronounced in the first few gigabytes of a disk.

Disk Partitioning for Unix

You want to have many filesystems because (among others):

• You're not putting all your eggs in one basket. If one filesystem becomes damaged, you restore it from backup, and life goes back to normal. If all of your filesystems get damaged, there's more downtime, more trouble, and you get more annoyed.
• Each filesystem can be tuned differently for performance reasons. The filesystem where you cold your MailDir can have hundreds of thousands of small files in a few directories. The filesystem where you hold video files has dozens of huge files. You can optimise.
• You can reserve space in the filesystem, and allow a certain user to use it when others cant. Root usually reserves 5% of a filesystem's space. With multiple filesystems, you can tweak this (e.g. mail spool filesystems can have the space assigned to the mail user).
• You're simplifying your backup policy, making one filesystem fit one backup medium. This depends on your backup policy and software.
• With separate filesystems for, e.g. /home, you can have multiple *nix operating systems on one computer and share your files between them, without having to come up with kludges.
• You can solve system limitations. E.g. in the past, some disks couldn't boot from disk blocks too far from the disk beginning, so we'd make a small enough /boot filesystem to occupy the first blocks of the disk.
• You can optimise for speed. Put critical filesystems in the fastest disk zones.
• Boot speed: fscking a 20G filesystem is faster than fscking a 1900G filesystem. Cunning selection of your check periods can ensure you spread out the fsck runs.

You may not want to have too many filesystems because:

• You're quantising the disk space. If you need to store 100G on the disk, you may find you have 200G free in total, but no single partition with enough disk space free.
• You're limited by the capabilities of your disk label. Many Unices can only fit 8 partitions/slices in a disk label, and one of those is reserved. MBR isn't very limited in this respect, and GPT will allow 128 partitions, which is much more than you need.
• Too many filesystems can be a nuisance to create and manage.
• Your file storage needs aren't so varied.

Filesystem Schemes

Everyone has their favourite. I used to have a spreadsheet to calculate those, but more often than not, I use a sheet of paper and one of those old-style writing implements (how quaint). I go through a number of iterations until I'm satisfied, and commit the partitioning scheme to the computer. It's faster this way. On most Debian-based servers, I keep the following filesystems separated:

• / (root)
• /boot
• /usr
• /var
• /usr/local
• /tmp
• /home
• spare filesystem

Additional needs get other separate filesystems, like a separate partition for my photos (the backup policy is different), a separate partition for videos, etc. Mail servers would get a separate partition for email. Database servers would get separate partitions for their data stores and on-disk, consistent database backup files, et cetera. But the base scheme is almost always this.

I also keep a spare filesystem at the end of the disk. I mkfs it and use it for scratch space, often mounted under /disk1 (work convention), or /disk/tmp (my convention). This filesystem is useful should I discover a new need (I can delete it and grow another filesystem, or just repurpose it), or if I just need a lot of scratch space.

Sizing

It largely depends on what the computer will be used for. You can get away with really small sizes for many things. My suggestion would be to use LVM (read on) and allocate 10G each to /usr, /var and /usr/local (smaller if you aren't planning on compiling and installing your own software). I keep /tmp smallish, maybe 1–2G. Without having all of the big filesystems in the root filesystem, that can also be smallish: my current box has a 2G partition and there's plenty of space left. The /boot filesystem can be very small if you're not a kernel developer, or left out entirely. Recent computers and recent versions of GRUB can handle that just fine. If you want it, around 200-300 megs will be fine.

LVM

I haven't deployed a non-LVM system in a long time. The flexibility you get is worth the short learning curve. With LVM, you get much, much more leeway to change your mind, and your filesystems can grow with you. I really recommend it.

An Example Scheme

• Partition 1: swap space (beginning of disk)
• Partition 2: LVM Physical Volume with a Volume Group called ‘fs’ or something.
  • Volume fs-root: ~2G.
  • Volume fs-usr: ~10G.
  • Volume fs-var: ~10G.
  • Volume fs-local (short for /usr/local): ~5–10G.
  • Volume fs-tmp: ~2G.
  • Volume fs-home: the remaining space minus maybe ~30G.
  • Volume fs-spare: spare space: ~30G.

On a 2T disk with a 8G swap space, your /home partition would be 2000 - 8 - 2 - 10 - 10 - 10 - 2 - 30 = 1928G.

The spare 30G partition will come in handy should you need more space for one or more of your other volumes. It's easy enough to resize LVM volumes (and ext{2,3,4} filesystems).

Note that there's no separate /boot, and that all of your bootstrap infrastructure (kernel and initrd) are inside the LVM. This makes some people uneasy, but I've never had issues with it. GRUB can see inside LVM physical volumes just fine. If it makes you uneasy, make a separate /boot of about 200M. Make it either partition 2 (making the LVM PV partition 3), or partition 1 (pushing down the other two).

Answer 2

MBR should work fine on a 2TB drive, but not on anything larger. It doesn't really matter whether you use MBR or GPT though, as long as all the operating systems you want to use support it. The BIOS doesn't have to support EFI to boot from a GPT drive.

Regardless of whether you use MBR or GPT I would recommend using LVM to manage the space, because it is a lot more flexible and easier to change at a later stage.

Answer 3

I think you're over-thinking this a bit. GPT vs MBR really only matters if you intend to install multiple operating systems or move the drive to another computer. If you can get away with MBR, then you might as well stick with it, especially if you're using LVM (which allows for many of the features that MBR is missing).

As for partition sizes, here's a few good rules of thumb:

• Small partitions can be annoying, since you never know ahead of time how much you'll actually use.
• Large partitions can be annoying because they take a long time to build and check. Also, "wear and tear" on filesystems tends to build up based on usage. Putting everything in one partition means that this buildup happens faster. For whatever that's worth.

Answer 4

Filesystems that turn out to bee too small are usually a drama. 10GB can easily be filled up with binaries and log files. You have a wealth of disk space, why are you trying so hard to save on space? You'll regret it in a little while. Don't assign disk space all at once, leave space to move filesystems about when required. Extending a filesystem is easy, shrinking it isn't. Check out what LVM2 can do for you. http://tldp.org/HOWTO/LVM-HOWTO/index.html Don't make bad decisions that lock you in for years to come.