Partitioning Tips and Tricks

Revision as of 10:29, 26 July 2005

Don't dump everything in /usr !

By default, FreeBSD will partition your drive so that the /usr partition takes up all the space except for a few hundred megs apiece for swap, root, /var, and /tmp. This is fine unless and until you wind up with a cranky machine that needs some TLC and keeps rebooting or panicking, thereby needing tremendous amounts of time to fsck a gigantic /usr partition before it can be booted!

You'll make your life LOTS easier in the event of problems if instead you set /usr to be no bigger than about 10GB or so, and put the remainder of the drive as a new and unrelated partition - I tend to call mine /data. That way if you're having problems that keep causing the machine to panic or hard boot without stabilising the filesystem first, you can get up and running FAST by just fsck'ing your nice small /, /var, /tmp, and /usr partitions without having to sit through a 15 or 20 minute fsck of the rest of the 100GB or so of user data that isn't needed for the system to actually operate.

Of course, you WILL need to fsck that big /data partition once you've gotten the system stable again - but at least you'll only have to do it once after the problem's been fixed, instead of sitting through a 10-30 minute fsck every time the machine panics or hard-reboots while you're tracking down that pesky hardware problem.

Make yourself a tiny little partition for /mnt

If you plan to work with removable read-write filesystems - USB drives, IDE or SCSI removables, whatever - make yourself a teeny tiny (like 5 or 10 MB) partition for /mnt, and mount the devices to /mnt/removable or /mnt/usbdrive or what have you. That way if a script or a command you run tries to copy a few gigs worth of data and you DON'T have your removable device properly mounted, it will fill your little throwaway /mnt partition that you don't really need (and do it very quickly), instead of you accidentally filling your root partition, which can cause system instabilities.

Use soft links to your advantage!

Don't forget that you can use ln to do really nifty things with your drives and partitions. For example if you've taken the first tip's advice and made a relatively small /usr partition and a very large /data partition, you might want to move the ports tree - which can occupy several gigs of space if you build lots of ports and aren't meticulous about cleaning out old distfiles and work directories - into the larger /data partition. But instead of trying to laboriously fix the entire system so that it looks in /data/ports instead of /usr/ports, what you can do instead is mv /usr/ports /data/ and then ln -s /data/ports /usr/ports - now it looks and works as though the ports tree is still in the default location, but in fact it's operating from the bigger partition!

Another common use for this is /var/db on servers with large databases. By default mysql places databases in /var/db, which is normally a very small partition (256MB or so) - and can be overwritten disturbingly quickly with apache logs and mailserver logs and the like, not to mention the databases themselves. Rather than recompiling or reconfiguring the database server itself to look for its database in a different location, you can simply move the databases to a different partition and soft link to them, just as was described for the ports tree in the paragraph above. Kill the database server, mv /var/db /data/db && ln -s /data/db /var/db and restart the server with no conf changes necessary, and you're in business!

Multiple Disks? Multiple /swap

If you've got two or more disks, you'll speed up performance on them by creating swap partitions on both of them -- no more moving data through the system bus to page files from disk 1 to your swap partition on disk 0. Some folks recommend that swap always be the first slice on the disk (even before / or any other partitions) because it's supposed to increase read/write times for stuff in swap; I've never noticed any real difference when I've done this, but if you have a lot of read/write-intensive operations (big databases, for e.g.,) you may want to consider this.