Divying up the root folders across multiple drives

[ElleStone]

Before asking my questions, first I want to say "Thank You" to the Gentoo developers and all of you Gentooers. When I switched to Linux back in 2005, I really enjoyed Linux. Somewhere along the line Linux stopped being fun. Gentoo has made Linux enjoyable again.

The question is how best to divy up root folders. My main computer has four sata hard drives: two sata 1.5 WD Raptors (70GB each), and two sata 3.0 Seagate Barracudas (120GB and 640GB). I use this computer for image editing, as a test lamp server (only one website, nothing fancy), and for source code modification. Here's my proposed partitioning:

*The first raptor: 4 partitions: swap (12gb), /boot (1gb), /root (35gb), and /virtualm (21gb, for virtual machine disks).
*The second raptor: 3 partitions: swap (12gb), /rwstorage (45gb), and /newphotos (12gb, temporary storage).
*The smaller Seagate: swap (12gb), /home (99gb, www and databases are in my home directory).
*The larger Seagate: /edit (148gb), /store (437gb).

To keep Gimp from totally choking when it runs out of ram, the three swap partitions are "swap-raided" per Daniel Robbins' article: http://www.ibm.com/developerworks/linux/library/l-swaptip2/index.html. So it's really only 12gb of swap.

I've been pondering Mr. Robbins' article: http://www.ibm.com/developerworks/library/l-partplan4/index.html. Mr. Robbins suggests linking /tmp and /var to a partition separate from the root partition. Imagemagick and other image editing programs use /tmp for temporary files, some of which can get very large. So it makes sense to give /tmp a lot of space. Also, I work a bit on source code, which means keeping up with several git repositories and also means frequently recompiling software. I usually install the compiled software in /usr/local.

So the "/rwstorage" partition on the second raptor would have at least three, perhaps 4 subfolders: "tmp" linked to /tmp, "var" linked to /var, "git" for source code and notes, and perhaps "local" linked to /usr/local. I considered real partitions for /tmp, /var, /usr/local, and so on, but that could result in "wasted space/not enough space" issues. So here's my questions:

*Does this seem like a workable partitioning scheme? Or is linking like this just asking for problems? In particular, will it cause problems with routine backups when links are involved?
*Should I link /usr/local to "local" on /rwstorage? Or leave it on "/"?
*Regarding partition sizes, if /tmp and /var and possibly /usr/local are linked to folders on /rwstorage, how big should the "/" partition be?

ElleStone

[NeddySeagoon]

ElleStone,

A few things on drobbins swap document.

I says that swap is set up like raid0. Thats striping for speed, so you get the benefit of all of your swap space but no redundancy.
That gives you 36G of swap.

You do not have the control you think you might today. That document is dated 2000 ... thats before the days of devfs, udev and devtmpfs.
On a modern system, all of your swaps will be mounted automatically with priority -1, so you get the raid0 effect and any entries in /etc/fstab will be ignored.

In the years since 2000, RAM has got about 10 or 15 times faster but HDD only about 3 or 4x faster, your Raptors being the exception.
So, if you make use of swap, you really need more RAM, though I can see how The GIMP will use all of the RAM you can throw at it, then some. Be careful of out of date infrormation.

I would put /boot on one of the slower drives, as its only ever used start startup and donate all of the rest of your disk space to Logical Volume Manager. Since you want to keep track of what goes on which spindle, you would have four physical volumes, from which you make logical volumes to hold your filesystems.

Its important that you choose filesystems that support growing and maybe shrinking. This way you don't have to allocate all your space at the outset and you can add unallocated space to a logical volume and expand the filesystem into the new space. With extX you can do that while the filesystem is in use too. Shrinking is a bit harder but is also supported, so you can move space around.
If you use KVM, you can donates one or more logical volumes as disk space for the VM. I think Virtualbox can work with logical volumes too but I've not checked. You get some performance improvements in your VMs as you don't have a filesystem in a file on the hosts filesystem.

As an example, I have

[ElleStone]

NeddySeagoon, thank you for taking the time to respond in detail. I've been pondering your advice very carefully.

[NeddySeagoon]

ElleStone,

For tuning filesystems, think about what you will put on them, how expendable they are and if you mind long fsck times.
For a large number of small files, you want a small block size and one inode per block. Think of the portage tree as an example.
Most of the files are less than 1k in size. They will each take one block, regardless of the block size. The tree is also expendable. Its well backed up on the web.
So, a 1k block size, no jourmal, one inode per block works well. you can remake this filesystem if it gets in a mess. -O dir_index may speed thinhs up too.

For a filesystem that stores large files, use a 4k block size. If its portages distfiles, its expendable too. A journal will speed up fsck but if you had to throw it away, it too is backed up from the web. You only need one inode per file, so if all the files were say 1Mb each, you need one inode per Mb of filesystem space.
Creating excessive inodes is wasteful. Not creating enough means remaking the filesystem, so have too many rather than too few.