Partition Suggestions Needed

If you decide to do it the way mentioned above there's nothing wrong with that - just make sure that your reserves are set properly so that if a disk fills up, root can still get in and remove files, etc ... otherwise you will have to boot either in single usermode or using a boot cd.

To make sure reserves are set use:

tune2fs -m <reserved blocks percentage>

so for example you can do:

tune2fs -m 1 which will set your reserved blocks to 1%

I hate to contradict mrcustard again, but the issues with being locked out of a system because the root filesystem was full (and thus /tmp and /var entries could not be made) were resolved out of Linux, Solaris, HP-UX, and even AIX nearly a decade ago! I know this because my courseware on Solaris & Linux Administration for Learning Tree International had to be updated back in 1999 to reflect MY being corrected on this matter by a student... I too used to warn students about the dangers of allowing / to become full... but the OS writing gurus made their systems MUCH more fault tolerant.  

NOTE: I also used to teach separating out all those partitions -- but once we started using 40 and 80GB hard drives, I was forced to re-evaluate the rationale, and I began recommending system builds with just 3 partitions (root, swap, and home).

Back in 1999, a terabyte of SCSI storage took a massive RAID array that would cost millions of dollars (LITERALLY!) I sold them (I was working with EMC at the time) That was 30 36GB SCSI drives, or 60 of them if you wanted RAID-1 data protection!. Today, I very nearly asked the original poster (rscurley) WHY he was using such SMALL drives (ONLY 250GB!). He could likely get better, faster storage out of a pair of 1TB drives in a RAID-1 array than he'll get out of the 6-250GB drives in the RAID-10 array! But, who knows -- maybe the 250GB drives are already on-hand! I chose not to question that....

Back to booting with a full filesystem. While you'll certainly not continue to get full functionality, the root user can successfully login to a CLI console with 0 bytes free on the root partition "these days". From there, the offending log files (or tmp files) can be removed and the system should be able to recover... although a reboot after such a "rescue and repair" is strongly recommended.

With regards to the "reserved" space... unless you specifically say so, the mkfs script for ext3 "reserves" 5% of disk space for "root access only" by default... which is STILL a heck of a lot of space these days... more than 10GB on a formatted 250GB hard drive... but at least it's less than the 10% that USED to be the default! *HOWEVER* the "root reserve" won't affect the ability of the system to fill up the root partition with entries in places like /tmp and /var/log because BY FAR, the majority of the data stored there is done by processes running as root -- so they're exempt from the filesystem restrictions to begin with!

Finally, in my example above, since ext3 is ONLY to be used on /, and since "standard" users should have precious little write access to /, the value of the "reserve" setting should be immaterial. What's more, since a typical Linux (RHEL5.3 -- I haven't seen 5.4 yet) should take no more than about 5-8GB, the 20GB I recommended should be capable of keeping some HUMONGOUS log files! :-)

So... I stand by my earlier recommendations without modification....

Dan
IT4SOHO