From owner-colug@bopper.wcbe.org Wed Nov 4 22:20:10 1998 Date: Sun, 01 Nov 1998 16:46:52 -0500 From: Rob Funk <rfunk@wks.uts.ohio-state.edu> Subject: Re: [COLUG] Linux/Win95 In-reply-to: <Pine.3.07.9810301350.A29022-b100000@login>; from Ryan Bagueros on Fri, Oct 30, 1998 at 01:40:50PM -0500 To: colug@bopper.wcbe.org References: <Pine.3.07.9810301350.A29022-b100000@login> Ryan Bagueros wrote: >Also, I've read a lot of different opinions on how to break up the >partitions for Linux. The very basic recommendation is to have /usr and / >on two partitions. Then sometimes people say to add another for /home >(perhaps this is only a security consideration?). I would split /home off before /usr, because when users fill up the alloted space, you'd rather not have it affect the entire system. On a typical standalone Linux system, I'd consider the following variations: # partitions specific filesystems 1 / 2 / /home 3 / /usr /home 4 / /usr /usr/local /home 4 / /var /usr /home 5 / /var /usr /usr/local /home (my favorite default) 6 / /var /var/spool/mail /usr /usr/local /home 6 / /var /var/spool /usr /usr/local /home /tmp might also be a candidate for separation. (Anybody done /tmp as a ramdisk in Linux? In Solaris, /tmp is free swap + free ram, which is nice unless you're running a program with a major memory leak.) Sometimes having an /opt is nice, for major packages that want their own hierarchy (such as applix, kde, wordperfect, maybe netscape) that you'd otherwise put directly under /usr/local. The Filesystem Hierarchy Standard (formerly Linux Filesystem Standard, FSSTD) discusses the uses of the various filesystems and things to consider when partitioning. I don't have the URL handy, though. (www.fhs.org?) A few issues to consider: What happens to the rest of the system when this partition fills up or gets corrupted? How separate are local data and changes from the as-installed OS itself? How often does this partition change? (this and the previous one are especially important when dealing with backups.) Is this partition needed during the early boot process? Do I want to share this by NFS or SMB? Do I want this to be read-only for anybody? > Anyone who would be >interested in giving me their opinion on the very best way to partition a >hard drive would be very appreciated. What I'm mostly interested in is >percentages, like, / should have 25% of available space, /usr should have >70%, etc. I don't think percentages are what's most important. What's most important is how much space you have, how much the machine is doing (including how many users you have), and how much you install. I first decide on some absolute partition sizes, then divide the remainder among the rest. A root without /var, /usr, /home, or /tmp only needs about 50M. Mine is 100M (and it includes /tmp), but only 36M is used. The size of /var depends on your logging, package installation, and spooling, but for a basic system I make it about the same size as root. (Which means a root with /var in it should be at least 100M.) The size of /usr depends on what you install as part of the OS, and on a 1G disk or bigger should probably be at least 300M. The size of /usr/local depends on how much you install separately, outside of the packaging system. The size of /home, of course, depends on how many users you have and how much space they take. On a big disk, I'd give /usr at least 1G, but generally divide /usr, /usr/local, and /home according to available space and how much you expect to put in /usr/local and /home. Don't forget to leave plenty of room for growth in all three of those, particularly /home and /usr/local. /usr tends to be more stable, though less stable in Linux than other Unices.
From owner-colug@bopper.wcbe.org Thu Nov 19 23:20:48 1998 Date: Thu, 19 Nov 1998 22:27:34 -0500 From: Rob Funk <rfunk@wks.uts.ohio-state.edu> Subject: Re: [COLUG] Harddrive Partitioning In-reply-to: <Pine.HPP.3.95.981119090359.28964B-100000@factory.cis.ohio-state.edu>; from alexander e dukat on Thu, Nov 19, 1998 at 09:16:24AM -0500 To: colug@bopper.wcbe.org Reply-to: colug@bopper.wcbe.org References: <199811191318.IAA02121@cis.ohio-state.edu> <Pine.HPP.3.95.981119090359.28964B-100000@factory.cis.ohio-state.edu> alexander e dukat wrote: >Here is my revision in light of below. I am still going to have some >things seperated as can be seen. > >/ 150MB Hey, I have room :) >/var 600MB Plenty of space for downloading >/tmp 100MB? Good size? Since stuff is added and deleted from here so > often I felt I should have it seperate. >/usr 2GB I'd recommend at least separating /usr/local, and probably /usr/src. >> alexander e dukat wrote: >> > /usr/lib/dpkg 300MB (where everything is downloaded in Debian before >> > setup) Actually that's /var/lib/dpkg, or should be anyway. >On Thu, 19 Nov 1998, Steve Roggenkamp wrote: >> The advantage to having many partitions is that it keeps the files in >> the partition contained to a narrow band on the disk, supposedly helping >> performance. With today's faster drives I question this somewhat. I >> prefer big partitions so I'm not always bumping up against a limit. >> That's a major pain. I also have a couple more drives on this system. Performance isn't the big advantage to partitions. Filesystem integrity, facilitating a logical backup scheme, as well as separating the "as-installed" OS from customizations, are the rationales I use in partitioning. The filesystems being written to most are the ones most susceptible to corruption, which is one reason to separate those from the ones that are read-mostly. Those partitions are also the ones that need to be backed up most often; no reason to do a full backup of /usr as often as /usr/local or /home, and no reason to backup /tmp at all. If you partition well, you can do a fresh OS install without losing any local data, just by not touching /usr/local or /home in the install. And of course, keeping user-writable areas separate acts as a crude quota system, preventing users from killing your system by filling up critical partitions. (Actually, real quotas go by filesystem anyway, so separating partitions gives you more quota control.)