Being new to Linux, I have been reading most everything I can find on
the subject. While this approach usually allows me to distill a set
of best practices for use in my own configuration efforts there is
one simple area in which I am unsure how to proceed: partitions!

Specifically, on a server dedicated to OpenACS what would a partition
scheme look like that would scale adequately as traffic grows?

Regards

Ask 10 people get 100 answers ;)

Jon is being conservative. You traffic isn't going to be really effected by your parition sizes. Except for where you place your log files, depending on your application you could even turn off logging for performance reasons. Probably where you stick your partitions is more important. How you mount paritions, if your server is connected to the internet.. then you can also mount certain partitions read only or no devices or no executables depending on security issues.

Sticking your files that are being served and your DB on faster drives such as SCSI gives a boost in performance. I have heard the arguments that IDE is just as fast as SCSI... but my expericence has shown than SCSI is definately more efficient with the controllers, drives, and applications I have tested. Place the files and DB on a RAID mirror. (BTW software RAID usually outperforms hardware RAID if you have a reasonable CPU -- except for very expensive hardware RAID cards).

Alot of this stuff you change to suit your needs. Just expect to reinstall your box a couple times before going live and afterwards to keep up with security issues. Your own benchmarks will tell you what you need to do. You really have to do your own testing when you get sites upto the point where you are tuning it. I have seen hardware RAID card performance vary alot with applications. IBM had a card that didn't do well with the through put tests of many labs but if you had an application that was causing more erratic drive head movements with smaller data reads its caching algo was much better and then provided a better through put. If you were streaming out MPEG videos from a video server... you were better off with something else.

Make sure you have a good backup and recovery plan that is *TESTED*. If recovery is simple... it makes also changes to your partitions/hardware later easy.

DISCLAIMER: I haven't deployed a Postgresql/AOLserver/OpenACS site yet. But have had experience with applications that require heavy network and disk usage.

As far as I can tell, the primary reasons to partition are a) preventing log / temporary files from growing without bound, and b) ease of restoring from backups (e.g. don't need to restore the stuff that came off your linux CD), or if your machine was compromised. You can physically go to the machine, wipe the OS paritions and reinstall from CD or restore from known good backups, while leaving the data partitions alone.

Also, partitioning is handy if you planned on keeping radically different sizes of data. If you were spooling a newsfeed fer instance, you'd want a filesystem with a whole bunch of inodes and a small block size. If you just had one or two big files (say a monster chunk of raw video), ten you'd want a much smaller number of inodes and a much bigger block size. Multiple partitions let you make seperate tweaked filesystems like that.

You can cause yourself all sorts of headaches if you go hog-wild with partitions, and discovered you planned incorrectly as one partition is bursting at the seams and the other is a vast empty landscape.

Personally on my rinky-dink little SuSE colocated box, I have a small /boot, then one big partition on one drive, and one partition on the next drive. Works pretty well for me

I'll take any opprtunity to spout off

If performance were job#1 and money were no object, performance wise you'd put your executables, database datafiles, server page root on seperate hard drives with seperate controllers to interleave I/O. If yo're just doing a single drive, any performance gains will be minimal due to partitioning. So then the question comes 'will a scheme help in my administration'? I can't think of much reason off the top of my head where putting the postgres stuff in one partition, plus aolserver / ACS on another partion will win you much. Granted, if someone fills up the ACS partition, it won't hose your database

Probably a lot will depend on your goals. If you're going to be hosting a group of relative strangers (say you're selling ACS hosting services), then putting each client on a partition could make sense to keep them from expanding outside of their given space. (there's probably disk quota stuff that'll do this for you as well, allowing you to change quitas on the fly you can't do with partitioning).

As you can prolly tell, I'm not a fan of a bunch of partitions. I've been bitten more often by poorly planned partitioning than I have had with something running amok and filling up an entire drive. Especially if you put transient or stuff likely to fill up an entire drive on its own partition to limit such behavior.

Like Mark, my old web site had a small /boot partition and one big /root partition. I had a couple of extra drives, each with one sole partition, from which I served up web pages, etc. The only thing that lived on the root partition was the OS. While it wasn't a database-backed site, it was serving up half a gig per day and getting hundreds of thousands of hits and it had no drive latency issues.

From a performance standpoint, your biggest gain will be from moving your web/db stuff to a second drive. No matter how clever you are in partitioning a drive, you still only have one disk spindle and one set of drive heads. A bunch of small, fast drives is better than one heavily partitioned big drive. Naturally, if you run out of space on a small drive, you can get a bigger one and move the data with a tar pipe. Changing partition sizes on a drive is a sysadmin headache.