> > Probably. Generally accepted practice in the Unix world > > separates /, /usr, /var, /opt, /home, and /srv (if used) into > > distinct filesystems. > > I'm going to have to respectfully disagree. > Making separate filesystems without understanding the _reasons_ for > making things separate filesystems is not a long-term recipe for > success.
Fair enough -- it's easily definable as a religious issue, so my feelings aren't hurt. We do it for manageability and making images disk-sharing-friendly. Separating / is a good thing, as it's hard to resize it non-disruptively. I'd argue that /usr separate allows more trivial sharing between guests, particularly if you plan to make /usr R/O on multiple systems. /var, /srv, and /home are by definition variable and generally contain user data, which usually has different access and usage patterns than / or /usr. /opt is a debatable one; depends on the Unix variant. In most of the versions I support, /opt behaves more like /usr than /var, so we treat it like /usr. > Most of the reasons are technical and related to the comparatively > limited hardware capacity of UNIX systems in the '70s and '80s. > Filesystems were split up so that they could fit on the disks which were > available at the time, and to simplify backups in an era of ~60 MB tapes > and tools no more sophisticated than 'dump'. > Now disks are huge and backup tools are sophisticated enough that > filesystem dumps seem hopelessly archaic. These are good things, in the > big picture. Umm, not really. As noted above, the different access and utilization patterns do provide reasons to split them out. > There's no reason to make directories which > are relatively static and are not subject to being filled by users into > separate filesystems. You've got much more idiot-free system administration and app mgmt groups than anyone I've ever worked for...8-). There's truth here, but there's also an argument for assembling your systems in the same way regardless of use. It allows rapid reassembly in another virtual machine quickly if something ugly happens to a system. > If you're running a server which won't have any > users logging into it, making /home a separate filesystem is pointless. > It adds to the complexity of maintaining the system without adding a > commensurate benefit. If /opt isn't going to have much in it or change > very often, there's not a lot of reason to split it into its own > filesystem. On the other hand, if you're doing logical volumes, making the LV for /opt and /home in these scenarios small, and assembling them in the same way is completely consistent, and I can then just expand the LV when I need more space w/o having to document "unusual" cases. Everything looks the same, and I always do the creation exactly the same way, regardless of what the server will be used for. This wins big if you're stamping out servers and don't necessarily know in advance what they'll be used for -- it's a heck of a lot easier to automate if I know every server is identical. It also allows me to do very fast automated surveys of configurations -- LVM can tell me a lot about utilization of LVs and how my physical storage is used. > If your site, like ours, isn't ruthlessly efficient at managing logfile > sizes, and your operators are basically punished by getting paged > whenever root hits 80% at three in the morning, and you can turn the > problem into something that can be dealt with in the morning by making > /var a separate filesystem, do it. Self-correcting problem, methinks. This is what automation is for. One 3 am stint for stuff like this, and logrotate becomes your best friend. 8-) > > /etc and /tmp are often also split out, but less commonly. > > I have never, ever, EVER seen /etc split out, or at least not as > anything other than a joke. Off the top of my head I can think of at > least four different varieties of UNIX which won't even boot if you do > that. Don't do it, it's completely unnecessary and will complicate your > life in needless ways. On the other hand, it's a fundamental assumption of the basevol/guestvol approach we're discussing. All the identifying bits that make a Linux server unique are in /etc. We regularly do it with Linux, Solaris, AIX, and HP/UX systems. Irix is a major PITA for this, though. UNICOS tolerates it. DUNIX doesn't. FreeBSD tolerates it. BSDI tolerates it. Certainly, it's not for the faint of heart, though. > /tmp is a different story. I've always really liked Sun's approach of > making it a transient, memory-backed filesystem. It seems that on a > hypervisor system like VM, where we are using VDISK for swap, there is > merit in doing the same with tmpfs on linux. We're about to give it a > shot and see how it works in practice. Whether you use VDISK or separate tmpfs filesystem, do keep in mind that it will dirty memory buffers at a accelerated rate, so your VM working set sizes will likely increase more rapidly. Splitting out /tmp is more important on systems with interactive shell users with heavy use of the traditional dev tools or lots of X users. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
