Date: Fri, 25 Jan 2002 15:46:07 +0100 From: Brad Knowles <brad.knowles@skynet.be> To: "Mike Meyer" <mwm-dated-1012390758.50933b@mired.org>, Brad Knowles <brad.knowles@skynet.be> Cc: chip <chip@wiegand.org>, freebsd-chat@freebsd.org Subject: Re: Bad disk partitioning policies (was: "Re: FreeBSD Intaller (was "Re: ... RedHat ...")") Message-ID: <p05101245b8771d04e19b@[10.0.1.3]> In-Reply-To: <15441.17382.77737.291074@guru.mired.org> References: <20020123114658.A514@lpt.ens.fr> <20020123124025.A60889@HAL9000.wox.org> <3C4F5BEE.294FDCF5@mindspring.com> <20020123223104.SM01952@there> <p0510122eb875d9456cf4@[10.0.1.3]> <15440.35155.637495.417404@guru.mired.org> <p0510123fb876493753e0@[10.0.1.3]> <15440.53202.747536.126815@guru.mired.org> <p05101242b876db6cd5d7@[10.0.1.3]> <15441.17382.77737.291074@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:39 AM -0600 2002/01/25, Mike Meyer wrote: > That's a different issue from keeping /var, /usr and / separate. I > actually do that by linking /var/tmp to /tmp, and mounting /tmp. That > solves all the problems of what to do about /tmp if it's symlinked to > /usr/tmp (which doesn't exist on my systems). That's another way to solve the problem, if you're willing to intermingle /var/tmp and /tmp. I prefer to keep them separate, with the option of making /tmp a small mfs, so that it's wicked-fast in addition to everything else. > It seems like all those extra partitions aren't providing any extra > protection - at least for the server I've got here. Indeed, my methods may not help you much with the system you have. It all depends on what is happening on the machine and how the various filesystems are being used. For machines that log a whole lot of data (mail systems with logging turned up to high levels for accounting or accountability reasons, web servers, etc...), I believe that things like this may be more important. > On the other hand, > as the various things in that slowly creep up in size, I won't have to > deal with it until the total space allocated is gone, whereas you'll > have to deal with it as soon as any one of them runs out of space. I usually install log file management tools that centralize all the log data from various machines onto a separate server, and very little (if any) log data is ever kept locally. I used to use syslog for this, until we discovered that we were losing something like 75% of all data being sent to syslog (since it's based on a UDP protocol), and yet still getting multiple gigabytes of log data that were produced on a daily basis. If syslog is used, I now prefer to syslog locally and then use other methods to periodically rotate the log file and move the old ones to a separate machine. > In my experience, that's true of workstations, but not servers. Then > again, I make sure that data files that need to change on servers are > configured to be outside of /usr/local, just to avoid that problem. I've seen this on the servers that I administered at AOL (as the Senior Internet Mail Systems Administrator, I was responsible for creating schemes that would work across all our hundred-plus servers), and I've seen this on pretty much every server I've ever installed or administered since then. Indeed, I've seen this kind of behaviour throughout the twelve-plus years that I've been doing Unix systems administration. The basic stuff in /usr doesn't change too much, but if you're keeping up with updates to packages that are under constant development, or if you're keeping up with the latest security holes & patches, I simply don't see any alternative -- if it's not in /usr/local, then it's someplace else and poses an equal problem/risk. > So what does this have to do with the case where you've blown 10s of > GB vs. / and /var being on different file systems? Well, since user-level programs can't write into the reserved disk space allocation (used to be ~10%, but I don't think that this really makes much sense with modern 100GB+ high-capacity disks, etc...), it doesn't completely and totally blow you out of disk space if they fill up what space they are allowed to write in. Since /var/log is a separate filesystem, having it fill up doesn't affect any programs that depend on use of /var/tmp (like vi, or any other system program that might need to create temporary files during operation). I also separate off the major applications into their own filesystems, too. So, the /var/spool/mail and /var/spool/mqueue on mail servers are separate filesystems (even separate from each other, so that mailboxes overflowing on /var/spool/mail doesn't prevent you from accepting and routing mail through /var/spool/mqueue and vice-versa), web servers get their own separate filesystem, etc.... -- Brad Knowles, <brad.knowles@skynet.be> H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7 Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/ uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101245b8771d04e19b>