Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]tlug: Partitioning sizes
- To: tlug@example.com
- Subject: tlug: Partitioning sizes
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Date: Tue, 26 Jan 1999 14:04:28 +0900 (JST)
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=us-ascii
- In-Reply-To: <199901260209.LAA10331@example.com>
- References: <36AC54EB.176485C0@example.com><1294807400-69404797@example.com><199901260209.LAA10331@example.com>
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
>>>>> "Dave" == Dave Gutteridge <dave@example.com> writes: Dave> I'm finally going to set up my own Linux Machine, seperate Dave> from the machine that i've been using so far from my Dave> office. As i'm sure everyone always does with every new Dave> task, I'm telling mysefl "This time i'm going to do it Dave> really, REALLY right!" :-) FWIW, here's my df: steve@example.com:VM$ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hdb1 19485 12871 5608 70% / /dev/hdb3 495746 452131 18012 96% /usr /dev/hdb5 99507 38392 55976 41% /var /dev/hdb6 495714 366877 103236 78% /usr/local /dev/hdb7 148319 136598 4062 97% /home /dev/hdb8 673217 621966 16477 97% /playpen Now, that's a LOT more than 1.2 GB but note the /usr/local and /playpen mounts. /playpen is my development area, and has two full XEmacs source trees, one full Emacs tree, and a kernel tree or two; /usr/local used have that in it and now has miscellaneous students' stuff. You can ignore them for your application ;-) I have a lot of extra stuff in /usr/doc (rfcs, etc) that most people won't have. You should consider consolidating that kind of shared data using NFS (or CODA, eventually). Keep docs on your road warrior (that's where the hard remote debug jobs are going to come up---you been there, done that already, ne?) Unless you're going to put the GIMP or Applix on that box, 512MB for /usr should be enough. Dave> The Red Hat 5.2 Manual says i should partition thusly: Burn those pages. Dave> 64MB swap This machine is a server, not a workstation, right? If so, I'd say 2MB swap for every 1MB RAM up to 64MB swap. (That's a little dated, I haven't really paid attention to this for a couple years.) Dave> 16MB /boot Huh? I have no idea why they'd suggest this. I've only got 90kB in boot. Put a couple kernels in there and it might go to 2MB. Dave> 256MB / I don't see any reason for more than 50MB, and that only for TurboLinux. For Debian systems I pretty much stick to 25MB. Take two, they're small. Every time you're about to do something stupid (install a new kernel, upgrade to a new libc, etc) that could hose your system, do dd if=/dev/hda1 of=/dev/hda2 Then with a proper lilo configuration you'll always have a bootable system, subject to no hardware failures on /dev/hda2. (Requires keyboard, sorry, but if you need this, a keyboard will be cheap.) Dave> 512MB /usr This is plenty for a Debian development system or any non-development TurboLinux system. I dunno Redhat, but it should be plenty. Dave> 512MB /home Pure fat for your application. But see discussion of servers, below. Dave> 256MB /var Pure fat for your application. But see discussion of servers, below. Dave> What differs from the last time when I set up the machine at Dave> work is that I'm I'm going to be the only user of this new Dave> system, so i'm suspecting i can reduce /home or /usr, but Dave> i'm not sure which of the two should be given priority. /usr, probably; that's where applications will go. Dave> Also, since a big part of this machine's purpose is to do Dave> mail services (albeit only for me at this point), should I Dave> increase /var? No. I have about 10 users on another box who mostly leave their mail in the spool (they've been warned, their suicidal tendency is not my problem). Never goes above 20MB. Unless you expect to be sending receiving mailbombs, aka Word attachments, or multimedia attachments on a regular basis, allowing 20MB for a single user's spool files is plenty. You can even skimp on that by using procmail to filter large mails into a holding tank elsewhere. You _do_ have to consider archival storage. What do you do with the mail? Read and delete? or Read and file? If the latter, you need to increase the size of /home. Dave> Just in case it will affect the answers - the machine is for Dave> web pages (no streaming audio or video but multiple domain Dave> names), FTP (no anonymous) and mail (me with multiple Dave> accounts and one mailing list) only. Where does RedHat put $WWWRoot and $FTPRoot? Debian puts them in /var/www, with the obvious implications for the size of /var. Exercise for the reader. I disagree with this in principle (but I'm too lazy to bother changing it), because I think that /var should be programs' scratch storage, projects like your Web page and so on should live in /home. Ah, is there gonna be a printer hooked to this machine? The natural unit for HP laserjet spool files generated by Ghostscript is `MB'; I've seen 40MB files in my /var/spool/lp. The idea is that everything that a human sweats over is under /home so you always back it up. The root partition gets backed up, since /etc is there. Some of /var needs backed up (/var/spool/mail in particular) unfortunately, but I prefer to minimize that. >>>>> "Stephen" == Stephen Carter <carter@example.com> writes: Stephen> I've found the "advice" in both the Red Hat and the SUSE Stephen> manuals pretty confusing, and when followed, doesn't put Stephen> enough space in some of the partitions to load the "One size gives all fits." Stephen> modules specified, and forces me to start over again--and Stephen> using Disk Druid isn't exactly the quickest thing in the Stephen> world! symlinks are a lazy man's friend. Make a directory where you do have space, move stuff there, and symlink it into the right place. Don't tell anybody I told you that was ok, though. Stephen> While I understand that the sizes of the various file Stephen> systems are going to vary depending on use, personal Stephen> needs, etc., can someone suggest a reference or two, or Stephen> perhaps have some insight on laying out file systems? Most of the distributions are File System Standard (FSSTND), now File Hierarchy Standard (FHS), conformant. Get this at any Linux site. On Debian systems you find them in /usr/doc/debian-policy/. This explains the rationale for the usual installation of files in certain directories. Unfortunately, the only way to figure these things out is by experience. None of the package systems tell you how big the various files are. However, in general nearly _all_ of the expanded size of the packages goes under /usr. So decide what packages you need, ask dpkg or rpm how big their contents are, add it up, and multiply by 1.2 because you know you are going to miss 20% of the dependencies. Sorry, I haven't written the script to do this. >>>>> "Dmytro" == Dmytro Kovalev <kovald@example.com> writes: Dmytro> Just personal opinion: I prefer to have separate /tmp and Dmytro> in this case 256 for / seems to much. What I have usually Dmytro> is something like: This is a _good_ idea (although I don't do it myself). One caveat: you need to be careful that your init sequence does not set up any files in /tmp that will proceed to disappear when you mount the /tmp partition. Eg, the X server puts its Unix domain sockets there. So you may need to special case the mount of /tmp. I have an overly large /var partition, so I set TMPDIR=/var/tmp in my environment. Most programs respect this, so it works for me. Caveat: automatic cleanup policies for /tmp and /var/tmp vary by installation, so YMMV. Dmytro> / 40-50 Dmytro> /tmp ~100 Dmytro> /var 40-50 Looks right to me. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." ------------------------------------------------------------------- Next Technical Meeting: February 13 (Sat), 12:30 place: Temple Univ. ** presentation: XEmacs, by Steven Baur and Martin Buchholz Next Nomikai: March 19 (Fri), 19:30 Tengu TokyoEkiMae 03-3275-3691 ------------------------------------------------------------------- more info: http://tlug.linux.or.jp Sponsor: PHT
- Follow-Ups:
- Re: tlug: Partitioning sizes
- From: Dave Gutteridge <dave@example.com>
- References:
- tlug: resolv.conf
- From: Neil Booth <NeilB@example.com>
- tlug: Partitioning sizes
- From: Dave Gutteridge <dave@example.com>
- tlug: Partitioning sizes
- From: Matt Gushee <matt@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: tlug: Re: Test messages: Where's good?
- Next by Date: Re: tlug: Re: Test messages: Where's good?
- Prev by thread: tlug: Partitioning sizes
- Next by thread: Re: tlug: Partitioning sizes
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links