Date: Wed, 27 May 1998 19:09:09 +0930 From: Greg Lehey <grog@lemis.com> To: chas <panda@peace.com.my>, Doug White <dwhite@resnet.uoregon.edu> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: adding 25GB as single partition ok ? Message-ID: <19980527190909.M24133@freebie.lemis.com> In-Reply-To: <3.0.32.19980527105421.0093fd30@peace.com.my>; from chas on Wed, May 27, 1998 at 10:32:16AM %2B0800 References: <3.0.32.19980527105421.0093fd30@peace.com.my>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 May 1998 at 10:32:16 +0800, chas wrote: > Thanks Doug, > >> You can't easily back up /var, at least using dump. > > I've actually picked up some good input from some Digital > Unix folks : > >> 2. The root partition looks a little small, I'd be more comfortable with >> 150-200mb. That might be right for Digital UNIX. It's far too large for FreeBSD. 40 or 50 MB is more typical. >> 3. Your /usr partition is large, but then I tend to split /usr/local >> (or /usr/opt if you come from an HP background) and /var off onto >> seperate partitions. In a configuration/security sensitive environment >> this allows you to mount /usr as read-only (make sure that the links >> to var are in place for directories that need to change) and only mounted >> read-write when the OS is updated. 1GB should be plenty if you split >> out your local and var files. The trouble with this scheme is that it's difficult to estimate the size of /usr, and FreeBSD is not laid out to easily mount /usr read-only. >> 4. As above, I tend to seperate out /usr/local and /var >> >> a. /usr/local is nice to have seperate, just because I don't trust the >> vendor's installers -- that way you can unmount it before any upgrades. This may be a Digital problem. We haven't had it on FreeBSD. >> b. /var is nice to have on a seperate partition because it contains both >> your log files and your crash dumps. If your system is attacked, both >> can start to fill a filesystem quickly. This is true, but you can use quotas. You can limit the amount of space that core dump files take by setting corresponding values in /var/crash/minfree, and there's no reason why you shouldn't include some script in the startup file to ensure that your /var/log/ directory doesn't get too big. Nevertheless, in this particular case, it may be justified if you're primarily a mail and news machine, in which case most of the disk would be /var. >> 5. If the 25GB raid set is to be used only for the mail spool, why >> not just mount it as /var/spool/mail or to be more flexable, >> /var/spool? Why not call the file system /var? >>> Are there any speed (I/O) considerations that would >>> suggest an alternative configuration ? (backup/redundancy >>> should be failsafe since it's hardware RAID) >> >> Speed-wise, if you could get another disk I'd strongly suggest using >> RAID 0+1 (somtimes refered to as RAID 10). RAID 5 and especially >> RAID 3 tend to bottle-neck with many small files. RAID 0+1 is a >> stripe set that is then mirrored by an identical stripe set. It has >> the all of the performance benifits of stripe sets and mirroring >> (round-robin reads) but is very costly in terms of disks (2 X capacity >> is needed). If possible, spread all of the disks out over controller >> chanels (HSZ) or at least put the stripe sets on different chanels >> (SWXCR). It also uses significantly more disk--depending on the RAID 5 configuration, up to double. >> Mail, as opposed to news, generates one spool file per user. Depending >> on the number of users, you may want to consider adjusting the inode >> or extent ratio that you use. >> >> I don't remember the max size for a UFS partiion, but if you are using >> UFS -- don't forget to set the inodes per kb down to one or two. This >> will reduce the avialable space bya small amount but will let you handle >> more small files. If this is primarily mail, you won't need to do this. If it's primarily news, it's a good idea. Remember that the only way to increase the number of inodes (files) is to re-newfs the file system, which involves a backup and restore of the complete Raid set. Even a fast tape drive (2 MB/s) would take about 8 hours to back up the data, and possibly about 12 hours to restore; count 24 hours uninterrupted work to rebuild it. > Also, we're hoping to use Qmail which everyone says will speed things > up. (if we can get it to work with Cyrus - next post) I don't know about "everyone". The jury's out about qmail. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980527190909.M24133>