Install tip: disklabel partitions
I've got a quick tip regarding how you partition your FreeBSD slice when you are installing. I'm not going to address the D0S partitions (or disk slices as they're
usually called in FreeBSD), but the FreeBSD partitions that will be put within the slice (or slices) that you install FreeBSD into. This is covered in the Handbook in the section "2.6.5 Creating Partitions Using Disklabel" found here (as of this writing).What I suggest is that you alter the default/auto partition recommendations of sysinstall by, at least, eliminating the "/tmp" partition, doubling (at least) the "/var" partition, and then sym-linking "/tmp" to "/var/tmp".
To do this is easy enough. During the install, when I get to the label editor screen I first press the 'A' to see the auto-defaults. Make a quick note of the order and sizes if you need it (I do) and then arrow down and delete all of the proposed partitions. (Remember they haven't actually been created yet.) Then re-add them in the same order, entering your new sizes (and skipping "/tmp"). I usually make "/" a little bigger, too. I would add "/" at 256M, swap at 1xRAM (assuming you've got plenty of RAM, 2xRAM otherwise), "/var" at 1G (for a workstation, more for a server), and the rest to "/usr". Then (important!), remember to create the sym-link as soon as you've rebooted. As root, these commands should do it:
cd /That's it. You're done!
mv tmp/.* var/tmp/
mv tmp/* var/tmp/
rmdir tmp
ln -s /var/tmp
I first got the idea to modify the default partitions from Greg Lehey's book, "The Complete FreeBSD." (A good book and freely available on-line now. See here.) The crucial point he made is that having many partitions was largely a defense against unreliable filesystems. But, filesystems have gotten much better in recent years. Given that, you shouldn't break up your disk into so many pieces without good reasons -- it creates unnecessary bottlenecks ("warning: filesystem full"). His specific recommendation was pretty radical, though: a single, large "/" partition of 4-6 GB, and the remainder of the space in a "/home" partition. (He was assuming a 20GB disk in his example.) I see the advantages of this, especially if you do a lot of work in your home directory that will use space. But, this recommendation has not stood the test of time, as my "/usr" partition is very often much larger than 6GB (to say nothing of when I must extract and compile a large port). Granted, disks (and software) are much larger than when Greg first wrote that, but it still fails to allow for the considerable wildcard of how much third-party software you may eventually end up installing. Also, if you let "/usr" and "/var" ride on "/" you've lost the advantages of the soft-updates for that IO ... or you've enabled soft-updates on your "/" partition and I don't like either of those options.
This article has become longer than I expected. I will follow-up on it soon with my thoughts on why and when you should throw in an extra partition.
Labels: installing
posted by kace @ 22:56
2 comments
2 Comments:
I just spent a while deciding on the partition/slice layout for my new server (well it's actually the same old machine but a new shiny hdd with lots more space!). Amazing how long it can take to decide on a good layout. In the middle of deciding I was half tempted to chuck it all in and just go for a single partition with a half dozen or so slices.
Some of the arguments I read/decided on when going for many slices/partitions:
like you say, many slices means there's no single point of failure if a partition fills up, esp if you have /tmp on a seperate slice for example or /var/log, both of which can fill up quickly on some rare occasions. I remember not long ago my /var/log filesystem being eaten up rapidly by some errant application that was spurning out thousands of lines of logs every minute and by the time I realized it was up over 5Gb or so! Great fun.
Another benefit of many partitions is easier backups. I've yet to see if this is a benefit to me, most filesystems I have don't need to be on seperate partitions but apparently some backup systems work better with fs's on individual partitions/slices.
Another benefit is allegedly speed increase. By arranging slices/partitions according to how often the data is going to be read/written to on the disk you can gain some speed increase. In this day and age though with uber fast 16mb cache disks I wonder how much difference this would really make. Still this was one reason I setup my partitions as I did, I made seperate slices for varous things like mysql dbs and webserver files and tried to arrange so they were at the start of the slice list. I left the other fs's that wouldn't be so often accessed to the end of the slicing list. I wouldn't be surprised if i got this the wrong way around or something though!!
As for disadvantages, one I actually came across luckily fairly early on after I'd sliced up my disk is not leaving yourself enough room on one of the slices. I'd made a slice to be mounted as /var/media for movs/mp3s/etc etc and after transferring the data I realized I didn't leave myself enough room on the slice for future requirements.
I think this is the worst thing about having a lot of slices - you can't be sure 100% in advance exactly how much space you'll need on any slice and always run the risk of leaving yourself short in the future. I kind of have a 'backup' plan for this in that if i do run out of space on say /usr, I know I made /home large enough that I'll probably always have enough room to symlink something like /usr/ports to /home/munk/ports.
Maybe a better idea would have been to just leave a bit of space spare and unsliced, I don't know... have to see.
Biggest drawback of all to lots of partitions though, takes so long to work out what partitions you want and you can overcomplicate things!!! That's what got me the most I think :)
Will be interesting to see how it works out with this fs layout I have now. So far I'm liking it a lot, being able to see at a glance from 'df' how much space i have left for media for example is quite nice and I made a bunch of samba shares, one for each major slice/partition like media/backups/www which is just cleaner and more obvious.
Anyway, long comment! Good luck with the slicing and dicing :)
I like putting /home on its own disk for backups.
Good article, Kace!
Post a Comment
<< Home