I have explained the sda/b1 as being Windows/spare, sda/b2 as two swap partitions, and the mirrored sda/b5 as an alternate OS. The extended partition mentioned by Trent which is annoying, but basically unseen, is sda/b4.
My first partitions are Windows/spare (which are generally unused), the swaps, /boot (which is only used at boot time), and a partition I call slackalt that serves as a nearly complete copy of my working Slackware system. I use the alternate for when I break something on my primary system, and booting into a system nearly identical to my own to do repairs is much preferable to using a live CD of a foreign system. (This partition can also serve as a location for installing alternate Linux distros when the mood takes me to experiment.) So the sda/b1 are for Windows/spare, sda/b2 are the two swap partitions, and the mirrored sda/b5 are an alternate OS. The extended partition mentioned by Trent which is annoying, but basically unseen, is sda/b4.
Now for the tricky part. My actual Slackware OS I have split into mirrored partitions I name boot (/boot), root (/, /bin, /dev, /etc, /lib, /media, /mnt, /proc, /root, /sbin, /sys), apps or applications (/opt, /srv, /usr), var or variable (/tmp, /var), and home (/home). It is fairly common to put /home and /boot on different partitions/drives. It is not so common to do as much as I have. What I have essentially done is separate out the top-level directories that change frequently from those that do not.
There is also a cryptographic element at work, so here seems an opportune time to explain. Frequently, when you enter some passwords into your system, they are transferred to, and stored, in physical memory. They can remain there until your computer is turned off, and even then, using some techniques, someone could get to them. There is little you can do about RAM itself, but because your computer swaps memory onto your hard drive, sometimes those passwords can be stored in swap. This would allow anyone who has access to your drive to take a picture of it at any time, then go about trying to find your passwords in the swap partition. It is for this reason that it is a good idea to encrypt swap. Similarly, passwords can end up in /tmp and even /var, and likewise it is also not a bad idea to encrypt them as well.
Usually, swap is encrypted each time at bootup with a random key and erases what was there from last time. But because we care about getting the contents of /tmp and /var back from session to session, we must use the same key(password) to get access to them each time. It is possible to have put them each on their own partition, but then I’d have to use two passwords to get to them. Thus, it was easiest to use a single partition for the two top-level directories I wanted encrypted, and encrypt the whole thing using one password.
You may ask why I didn’t just encrypt the whole OS? I only have 1GB of RAM at the moment and I use it pretty well already. I simply wasn’t willing to encrypt a lot of stuff that doesn’t really need it and suffer a performance hit that extensively.
Now this is the really interesting part and it affects partitioning directly. How you set up your system will depend on how much encryption you want to use.
- Swap will pretty much always get its own partition because you want to use a randomly generated key each time. But! you might not want people knowing that that part of the hard drive is swap because then they can go to work on it trying to decrypt passwords there as compared to searching through the whole drive. So if you’re going to encrypt the whole drive, you might want that encryption done first, and then potentially encrypt swap with its random key within the first (though this would double the encryption on it and really hurt performance). More, suspend to disk on laptops can have issues with encrypted swap. I am by no means an expert in this particular, so I’ll refer you to Google and more knowledgeable hands.
- /boot is almost essentially unencrypted as the computer has to access it before it knows how to start decrypting anything. But! you might put the kernel image and other necessary files in a ramdisk and store it on a CD or flash drive, and then boot from there, allowing you to completely encrypt your system drive.
- /tmp and /var are security holes. Many programs don’t think twice about storing potentially dangerous information there; sometimes even unencrypted passwords, but more often recent document lists and such that you would prefer no one know existed at all.
- /opt can sometimes have similar security holes.
Ultimately, how many passwords you want to enter is going to determine how many partitions you wish to use. Potentially, you could encrypt each partition with a different password, and then have to enter all of them each time you reboot. Most people are only going to want to enter one password so most people will make two partitions, one for /boot and one for the rest of the system. What you do is create a single partition, encrypt it, and then use LVM (Logical Volume Management) to make all the logical partitions you want within the encrypted physical partition.
This is all independent of RAID arrays/mirrors (which also happen to be logical volumes of a sort). In the example above you would simply create the raid mirror first, then encrypt it, partition that crypto device into logical volumes via LVM, then format those with your file system of choice (e.g., ext3), mount each, and use. In other words, the mirror is transferring encrypted data to the second disk. It doesn’t care that there are partitions within or not, it’s mirroring the encrypted bits exactly as they are.
It’s pretty crazy (and cool), but they’re all just imaginary devices pointing to other imaginary devices pointing to real devices. Which means they’re all basically links at the device mapper layer of the kernel, and you can link however many times you like. Taking this further, you could mirror two sets of drives -> encrypt each mirror -> LVM partitions each mirror -> raid stripe one partition from one mirror with another partition from the second.