Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

What Are Appropriate Sizes For Linux Partitions? 35

Posted by Cliff from the looking-for-suggestions dept.
stuyman asks: "I'm amazed that I haven't been able to find a good source of information on this sort of subject, but it seems that all anyone ever says is that it needs to be determined based on "certain factors" on an individual basis. No one ever says how to evaluate those factors. I need to set up a whole bunch of new Linux servers. How big should the partitions be? Anyone have any formulas or ideas? I'm open to superstitions, too (heads, root is 300, tails it's 60). Some quick details about the setup: We've got a 20.5 gig HD and we want to have separate partitions for /, /var, /usr, /usr/local (maybe), /home, /opt, and /tmp, as well as a sufficient amount of swap. The servers will run RedHat 6.2 with Apache stronghold, and will also need X installed. We're currently leaning towards having huge /usr and /usr/local, with about 2 gigs for var. Also, how much /var would one suggest for a syslogd server that'd be serving logs for 50+ boxen? (running mostly RH or SunOS) Awaiting this thread eagerly..."
This discussion has been archived. No new comments can be posted.

What are Appropriate Sizes for Linux Partitions? More

What are Appropriate Sizes for Linux Partitions?

Comments Filter:

  • Scale it up / slice it up as appropriate.

    First: Two hard disks, one 13.6 GB, one ~3 GB.
    Sizes reported as from `df -h`
    /dev/hda1: / (1.4G) (1.3G Free)
    /dev/hda5: /boot (23M) (15M Free)
    /dev/hda2: /home (3.4G) (1.9G Free)
    /dev/hda6: /root (486M) (455M Free)
    /dev/hda7: /var (243M) (203M Free) /dev/hda9: /usr (6.8G) (4.8G Free)
    /dev/hdb6: /mnt/data (2.9G) (1.0G Free)

    Swap partitions are /dev/hda8 (125M) and /dev/hdb5 (120M).

    It's a single-user workstation, really. /home is huge because I've got mucho MP3s. /usr is understandably huge. / is larger than most people would like, because I want to catch programs that land in /opt. /var and /root are awfully big for my application, because I originally installed Linux dual-boot with NT on hda1, and when I deleted it (hoorah!), I moved partitions around. /var was originally /root, /root was originally /home.

    Hope you find this useful. /home should be large enough at 3GB for many users, if you impose quotas (at my school, it's 15MB per user). / and /root could be smaller, as could /boot (I keep at least three kernels in lilo, and backup copies of each one). Make /usr (and /usr/local) really big, maybe equally sized to fill the disk.

    Good luck.

  • I have a couple systems with 20 Gig drives running Red Hat 6.2. Here's what I've found:
    1. I did complete installs on both machines. That took up about 2 Gigs without any extra goodies like CPAN, source code, etc. Other than that, I don't use /usr much at all. I did put my Java stuff in /usr/java, but that could go anywhere. /usr should be about 3 Gigs so you don't have to worry about overloading it with RPMs, but you don't waste too much space either.
    2. /home and /usr/local should definitely be separate partitions. I've reinstalled systems many times, and it is very nice to be able to save all your personal files and custom-compiled stuff while reinstalling everything in the distribution.
    3. Make /usr/local big. Really big. :) One thing you don't always count on is how much space source code takes up. The unpacked Linux 2.4 kernel source takes up 130 Megs! Just to make a 1 Meg file! You don't want to have to delete your source because you ran out of space. On one system with a 8 Gig drive, I made /usr/local way too small and ended up having to put my stuff on /usr in a directory called /usr/extra. It wasn't pretty.
    4. I have JRun installed on one machine. It went in /opt, but only took about 30 Megs. However, it expects a lot of its data to be in the same directory, so if I used it more, that could grow enormously. You can never be sure exactly what the closed-source commercial applications will want.
    5. A /boot partition at the beginning of the disk is nice, because it frees you to do whatever you want with the root partition without worrying about the 1024-cylinder BIOS limit. I made mine 16 Megs (which turned out to be more like 23 on a 20G drive), because I wanted to choose between a number of 2.2 and 2.4 kernels on startup.
    6. /var is pretty small unless you start using stuff like MySQL, which stores its data there. I use MySQL, but I compiled it myself, so the data is in /usr/local/var, which isn't a problem. Right now my /var has only 19 Megs used, including two printer spools.

    I might warn against overpartitioning, that is, to split everything into dozens of itty bitty partitions. Then later, when some of your partitions are nearly empty and others are bulging at the seams, you're screwed. But again, I highly recommend having /usr/local and /home separate. As for swap, IMHO, more is better. I use about 192 Megs, since that's what my systems have. If, after you've accomodated everything, you have extra space, put it in /usr/local. It's the easiest partition to fill.

    I'm not an expert sysadmin, but that's what's worked for me.

    -Andrew

  • two disks:

    first disk:
    /boot 15mb
    / 125MB
    swap 125MB
    /var 7.6g or whatever

    disk 2 is the same.

    the /boot partitions on both are kept the same by hand. / and /var are raid1's and /usr and /tmp are symlinked to /var/usr and /var/tmp at install time.

    why: this gives the maximum amount of space where it is needed, whereever that might be. For upgrading, /var has space to store packages, compiling, /home has space for source tree's. And if a drive fails, you have a second copy of everything.

    LVM and dynamically sized partitions are the next closest thing, but you still have to change the size with lvm.

    Oh, and having /usr and /tmp on /var doesn't matter. If you haven't mounted /var, alot of programs in /usr won't work anyway.
  • Performance can be an issue. If you run a mail or news server, /var (actually /var/spool or /var/news) would be a seperate drive or drive array for speed.

    Another reason is security. if you have / as your whole drive, and some cracker attacks your box, they could cause /var/log to grow till it swallowed the whole partition and took down the machine. seperate /var and / help this slightly.

    Same thing if / is the whole machine, and you have a user who fills their home dir. /home and / seperate also fix this.

    It's a combination of security and performance that dictate what should have it's own partitions.

  • I realize you are using only one 20GB drive. If you can get your hands on a small extra hard disk, and dedicate it to swap, the performance benefit can be tremendous.

    Why? Reduced head motion. Instead of having to slew back and forth from swap and whatever application files your using, the heads for the swap area are always near the data.

    For the sizes you are talking about, even a 1GB drive would be HUGE, and you can get a really FAST DISK for relatively little money these days.

  • Also, why on earth do you want so many partitions? If each was going to be on a different drive, it would make sense to break them up. However, you write that it'sall going to be on a single 20 gig drive.

    for one thing, i know graphics arts people that like to format and recreate filesystems between projects to eliminate leftover fragmentation. that's mainly ntfs on win32, however. i'm the wrong person to tell you how reiser or ext2 deal with fragmentation.

    other than that, i hardly ever partition my systems to any great extent. my home machine has 4g for root and 8g for home, but they are seperate drives.

    i can see the logic in making user a /usr seperate partition. that and mounting it noatime is a handy trick for getting that ipmasq gateway's disk to spin down.
  • My intent here was to have two 10G disks instead of one 20G disk, and partition them in a way so that if one disk failed, I could keep running essential stuff (like news, mail and the web server) on one until I could buy another. That's why each partition on /dev/hda has a corresponding partition of the same size on /dev/hdc. I have a nightly script that copies [...]

    I have a similar philosophy, but just used mdtools to set things up as a RAID1 across two 13 gig drives. Everything but the root partition is on the RAID, and I made a manual copy of the root partition on the second drive. If the secondary drive dies, no problem. If the primary drive dies, I use a floppy to boot off of the secondary drive's root partition, and again no problem.

    I haven't been brave enough to yank a drive to test this. I also suspect that my recovery skills aren't up to snuff; however, mdtools leaves a valid ext2 filesystem on each of the partitions, so in the worst case I can mount the valid drive's partitions as ext2 and spend several hours shuffling files to another drive, wiping the RAID drives, and reconfiguring the RAID.
  • Also, why on earth do you want so many partitions?

    This is one of the big problems with the success of Linux. All the new users are all well and good, but they don't know the reasons for doing things a certain way. Partitioning is one of those things (and is not helped by crap like Corel Linux which installs everything into a single filesystem).

    Basically, partitioning should be as follows:

    • Have a small root filesystem. This contains the bare essentials needed to get the machine up and running. Historically, this has been small to allow quick recovery after a crash. Once journaling filesystems for Linux become commonplace, this will be less of an issue.
    • A separate /var. This filesystem holds all your variable data. You don't want a rogue process (or processes) filling up your root filesystem, so you make /var separate. The size of /var will vary depending on what the machine is used for. A typical workstation can have 200MB or less. Large servers could have several GB (and will typically have extra filesystems specifically for /var/spool/mail, /var/spool/lpd, etc.)
    • If you don't give /tmp its own filesystem, make it a symlink to /var/tmp. Again, this is to prevent the root filesystem filling up.
    • Make /usr big enough to hold all your commonly installed stuff, and then mount it read only. Linux systems behave badly in respect to /usr. Most 3rd party RPMs (e.g., CorelDRAW) only install into /usr, and aren't relocatable. Not only is this in violation of the FHS (which says that sort of stuff should go into /opt), but it seriously screws with resource planning. Consequently, if you plan on adding stuff via RPM, allow enough extra space in /usr. On a typical RH6.x system, a full install requires about 1.2GB for /usr, plus whatever else you plan on adding there.
    • /home gets its own filesystem, again, to stop the root filesystem filling up. I personally use /usr/local/home for home directories, so I leave /home on the root filesystem, but you get the idea.
    • /opt should get it's own filesystem, and should be mounted readonly. /opt is for optional extra software, typically supplied by a third party.
    • /usr/local is your own place to play around in. If you give it a filesystem of its own, then, like home directories, it can be left untouched when you decide to upgrade the OS.
    • I tend to have a small /boot filesystem as well, mounted read only. This isn't essential, but it has historically allowed me to have a small /boot below the 1GB limit that LILO can boot from, and put the rest of the OS wherever I wanted. Now that LILO can boot from above 1GB, it's not such an issue, but AFAIK, all the Linux distributions that use LILO still ship with the 1GB-limited version

    For your 20GB drive, then, I'd have a 50MB /boot, a 100MB /, a 300MB /var, a 3GB /usr, a 3GB /home, a 6GB /opt, and whatever else is left as /usr/local. Make /tmp a symlink to /var/tmp, and you're all set. Depending on how much stuff you're planning to serve with Apache, you may want a separate filesystem for that, but only you can make that decision.

  • I was at a SUN course about a year or two ago and the representative was suggesting that admins move away from seperate partitions for everything and just have / and swap (prefer swap to be on a drive where the main executables don't live) and for big storage arrays just /export/home1 ... home10 ... etc depending on your physicaly drive layout.

    As for like everyone else is posting, we just jumpstat at work and here is an layout file for a typical system with a single 18g drive:

    # sa_profile_4u_18g
    # ONE 18 GIG drive with 2GIG of memory.. (swap = 2X memory)
    install_type initial_install
    system_type standalone
    cluster SUNWCXall
    partitioning explicit
    filesys c0t0d0s0 500 /
    filesys c0t0d0s4 1000 /var
    filesys c0t0d0s6 2000 /usr
    filesys c0t0d0s3 10500 /tmp2
    filesys c0t0d0s1 free swap

    as you can see quite a wast to /tmp2 but /opt and the like are mounted remotely from file servers. However, we do use a different config for a group here doing some sort of Physical Design and Engineering work that needs a large /var/tmp

    # sa_profile_4u_18g
    # ONE 18 GIG drive
    install_type initial_install
    system_type standalone
    cluster SUNWCXall
    partitioning explicit
    filesys c0t0d0s0 600 /
    filesys c0t0d0s4 2000 /var
    filesys c0t0d0s3 9000 /export
    filesys c0t0d0s6 900 /usr
    filesys c0t0d0s1 free swap

    As you can see we aren't even all that diligent about keeping root the same - and we feel we are making everything hudge so as it is!

    But again, sun was telling us that it might be a good idea to re-think using complex layouts.
  • You would be much better off using reiserfs. In case someone does kill the power for what ever reason, you will be much better off.
    And yeah it is stable, even though it is not included in the main kernel yet.
  • When you get right down to it, on a user's workstation with a single drive and no plans for expansion of the box's role, why wouldn't you keep everything in /root?

    Well, the guy said he was setting up servers, not workstations, so this is really not relevent to his question. Also, I'll assume you meant put everything in / , not /root. ;^)

    Anyway, I used to have a setup similar to yours, but lately I've decided I like to have a /usr/local because if I upgrade, or change to a different distribution, I can keep my locally compiled programs and locally written scripts safe while still wiping the rest of the drive clean during reinstallation.
    ---------------------------
    "The people. Could you patent the sun?"

  • Now you've got me confused. I can't remember when I did that test if I was actually booting off that disk, or booting from a boot floppy. But even if I had to boot from a floppy, I'm pretty sure I can mount what is currently /root_shadow as /.

    Ok, add one other thing to my list of what I'd change if I had to do it again - I'd make sure /root_shadow was near the beginning of the drive.

    --
    A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.
  • I'll third that. I only bothered with 2- / and swap. The problem with partitioning is that you're then stuck with one particular shape. It's like buying a biscuit making machine and then deciding that you're going to make cakes.

  • My scheme (Score:3)

    by ptomblin ( 1378 ) <ptomblin@xcski.com> on Sunday August 06, 2000 @03:19AM (#876627) Homepage Journal
    It's not perfect, but it's mine:
    /dev/hda1 101075 83487 12369 87% /
    /dev/hda10 4408138 1827348 2352669 44% /backup_1
    /dev/hdc10 4423964 4023975 171049 96% /backup_2
    /dev/hda5 1981000 1255590 622998 67% /home
    /dev/hdc5 1981000 619979 1258610 33% /opt
    /dev/hdc9 99507 72393 21975 77% /root_shadow
    /dev/hda8 101075 2195 93661 2% /tmp
    /dev/hdc6 991000 767770 172026 82% /usr
    /dev/hda6 1981000 420730 1457858 22% /usr/home
    /dev/hda7 995115 98461 845248 10% /usr/local
    /dev/hdc1 1981000 206648 1671941 11% /var/spool
    /dev/hdc7 99507 306 94062 0% /var/tmp

    If I had to do it over again, I'd make / a bit bigger, and maybe make another partition for /var.

    My intent here was to have two 10G disks instead of one 20G disk, and partition them in a way so that if one disk failed, I could keep running essential stuff (like news, mail and the web server) on one until I could buy another. That's why each partition on /dev/hda has a corresponding partition of the same size on /dev/hdc. I have a nightly script that copies everything in / to /root_shadow (and yes, I tested that I can yank hda out of the system and boot from hdc). I also have the nightly script copy stuff into /backup_1 and /backup_2. (This is as well as backing up to tape - call me paranoid).

    --
    A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.
  • Are these going to be worstations or servers? What type of servers? on workstations with default installs im always running out of room in / ..as far as swap goes settup a test box with the configeration you want monitor memery usage and load it down 2x the load your expecting and set your final swap to 1.5 times this size. For logs it sounds like your setting up a dedicated machine which is good so use as much space as you have. The worst thing you can do on a server is do a default install of most linux distros install the least amout of stuff possible then add what you need. Then on your test system see how much room each one uses and add a little to each for future upgrades and take it from there. my box? 3gig / ~7gig /home 128meg swap not ideal but it works

  • What I do... (Score:3)

    by Wakko Warner ( 324 ) on Sunday August 06, 2000 @04:35AM (#876629) Homepage Journal
    / doesn't need to be big, if all you've got in it is /etc, /lib, /bin, and /sbin. Mine's about 90 megs or so.

    /usr, if you're gonna have a separate /usr/local (and you should have an /opt, by the way, for "payware"), should be a couple hundred megs.

    /usr/local should be a gig or two. Especially if you're using huge bloated apps like emacs or the Gimp, which can easily chew up 60 megs alone.

    /home -- make it as big as you can. I find I'm running out with 2 gigs.

    /var -- if you're hosting a huge amount of mail, make it large (a gig or so). If not, don't bother. Mine's about 400 megs, and I've got plenty of room.

    /tmp - I like to compile stuff in /tmp. Yes, I'm bad. A gig here for me.

    Now, you need space for "other crap": mp3s, temp space for other packages, download space. I use the "sandbox" scheme:

    /dev/sde1 8746648 7321200 981136 88% /sandbox3
    /dev/sdd1 4307423 3763192 321312 92% /sandbox2
    /dev/sdb4 1416229 1008444 334602 75% /sandbox1
    /dev/sdc1 4102112 3562837 327008 92% /sandbox0

    Which I stole from Northeastern's CS department scheme, just because it seemed cute. All the stuff I'm about to burn to CD, or have downloaded and want to fool around with, or that's a big lame work-in-progress that won't fit in /home goes somewhere in there.

    - A.P.

    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • I went and read Chapter 11, which talked about partitioning multiple drives, but only in very general terms. That still doesn't answer his question, which was how to partition a single, 20.5 GB drive.

  • /usr/local (Score:3)

    by eMBee ( 27441 ) on Sunday August 06, 2000 @04:37AM (#876631) Homepage
    first, DO NOT combine /usr and /usr/local
    /usr/local is very dynamic, depending on what you put on there, while /usr is pretty static.

    how much you allocate for each partition mostly depends on how flexible you are and how long the system will run without adding diskspace.

    /: on my redhat 6.2 disk takes about 40MB, 6.1 takes 50, i don't know why there is that difference, it is likely that i installed less stuff on the 6.2 machine, my / have a size of 70MB.

    /usr: when i installed rh 6.1 i allocated 1GB for /usr, it eventually turned out that it was not enough, as i wanted a fairly complete desktop install. for your servers this will be a lot less, as you don't need all the games and stuff.
    i'd suggest you make a test install of what you want to have on your system, see how much /usr needs, add 50% to have room to grow, and use that.

    /home and /usr/local: these two are really individual, there is no way to generalize on those, some people do not need anything in /usr/local because they hardly compile and install their own software, others do a lot more, same for /home, it is really not to say...
    i often found out that no matter what i chose, one partition ended up to small.
    one way to combat that was to make sure both partitions have a different size (like 5GB and 8GB) that way, if you find that one partition was to small, and the other to large, you can exchange them, or move the larger partition to a new disk, and move the smaller to the larger one.
    if you want real flexibility, combine them:
    nowadays i have a large partition in /local and link /usr/local -> /local as well as /home -> /local/home
    that way, it doesn't matter...

    /opt: do you really need it? are you sure? well then same considerations as for /usr/local and /home, and if you want flexibility, again, combine (/opt -> /local/opt)

    /var: this depends on how much data you want to keep, don't like log rotation? better make it very large, otherwise a few 100 MB should do.
    but, consider mail, have lots of users? you'll need lot's of space in /var/mail
    on one system (debian) we had to go as far as putting /var/mail on a seperate partition and use user quotas on it too, to make sure everybody could get their mail...
    but we also had to split up the rest of /var. to make sure that in case of a full disk only a few systems are impacted, we now have a seperate /var/log (1GB) (which is only 4% full) /var/spool(1.5GB, 29%full) and the rest of /var(1GB,26% full), this is for a smaller server with about 150 users, which also just received a renewal, so the sizes are desigend for growth (the previous system had a lot less space)
    the isp i work for, unfortunately opted for the "don't partition at all" approach, so i can't say anything about that (we have load balanced machines and the data is kept on raid, so the situation is different)
    to make further growth easy, we have several partitions that we keep empty and hide away from the users so we can add them to the system as needed while keeping the users disciplined because they don't know about that...

    /tmp: another very variable thing, your diskspace is limited, but users may temporarily need lots of it for compiles? make it large!
    there is plenty of rome in /home? you don't need to worry so much about /tmp then.
    want to make the best of your recources? consider combining /tmp with /var, that's what i do (/tmp -> /var/tmp), works fine.

    greetings, eMBee.
    --

  • gimp and emacs come with every distribution nowadays, so they will not end up in /usr/local
    unless you are one of these guys with to much time on your hand and compile those on your own...

    greetings, eMBee.
    --

  • You forgot to list your swap space. I was surprised to see how tiny a swap partition was created by a default Red Hat 6.2 installation.

  • First, what are you doing with these systems? Where I used to work, we had /usr be 1-2G, and /usr/local 3-4G, because everything we did relied on specialized software. 1-2G for /usr was overkill by far. I'd recommend, for a syslog server, 200M / (first partition, or separate out /boot with 50M), 2G /usr, 2G for /opt (does anything but KDE in your setup use this?), and 1G for /tmp (and for the idiots out there, be clear that it doesn't get backed up). You must evaluate your needs for /var and /home yourself, since /home is dependant on no. of users and what sort of crap they'll stick in there, and /var depends on what you'll stick in there. I'd recommend 200-500M per user at most, and for a syslog server, everything else in /var. For a web server, however much space you need plus a gig or two for /var; for a mail server, whatever is left from the others (1G per user should be more than enough).

    Your "details" about the setup were useless, though -- the important information is:

    • /var-based network services provided (mail, web, syslog, DNS), and estimated use
    • additional software installed into /usr or /usr/local (for most things, this can be one partition, but not necessarily)
    • /opt-based services, and estimated space used
    • estimated required RAM, amount of RAM available, and estimated upper limit of use
  • Sounds good, but I'm wondering how you boot from hdc9. From what you show and say in your description you copy / to /root_shadow, and no mention of another partition with the kernel in it. That seems OK for a backup, but you also say you can pull out the hda drive and boot of hdc. Do you have another primary partion that's not mounted that allows you to do this? Or does the new LILO with support for >1024 cylinders do this, another boot manager, your BIOS, etc... You've got me wondering. I know people who are trying to get dual-boot and the only problem is the partition ends up being an extended at the end of the drive and they need a boot floppy.
  • I used to go through the same dillema every time I setup a system, then I discovered Veritas Volume Manager! You can adjust things as you need them changed. I don't know what type of environment you're in.. but I was always in fairly small environments, and sometimes a system purpose would change drastically, 6 months after it was up. And you don't want to have to move all the data over someplace else, rebuild another file system, etc etc.. With Veritas, you can just go in and change the size of the volume (partition), and the filesystem, with just a few short keyboard clicks.. and I think it even has a nifty GUI, where you can drag and pull and stuff. Check it out at veritas.com. as to your question.. make the place you'll be storing data big.. (not sure where that will be on your system).. make the place you'll be storing binaries, not so big (a gig or so over what you need initially).. and make the partition your logs will be on huge. theres nothing worse than having your /var partition fill up at 3am...

  • ...You probably don't know enough about how you are going to use your system.

    Also, why on earth do you want so many partitions? If each was going to be on a different drive, it would make sense to break them up. However, you write that it's all going to be on a single 20 gig drive.

    On my personal systems, given how cheap disk space is now, I only have two partitions. One is root with two gig of space. Everything goes here except personal files. The other is /home where everything else goes. On a single-user system that has little in the way of new software after the initial install, this works great. (Assuming you correctly rotate logs and such.)

    On production nodes, it is never that simple. The first thing you have to do is determine what partitions are static and which are dynamic. For example, /usr and /sbin are hardly ever going to change. Install them tight. On the other hand, /dbhome/oracle/data will get larger by the day. Make sure you have enough room out there for your dynamic partitions.

    Of course, since you only have one drive, you may want to take the easy way out. Why not have one and only one partition: root. If you will never fill the full 20 gig and these are workstations and not servers, why have the headache? (I suggest these are workstations because X is being installed and no one in their right mind would bog down a server with X. Am I right in thinking that these are development boxes of some sort?)

    I know I will get flamed for the above suggestion. Mostly from the clueless, of course, but there will also be some smart people out there who will find me insane. I hope those gurus will think twice before posting.

    When you get right down to it, on a user's workstation with a single drive and no plans for expansion of the box's role, why wouldn't you keep everything in /root?

    The only thing I can come up with is backups but 20-gig is small potatoes so I can't imagine that's much of a concern. Especially if the backups are incremental. (ADSM/TSM rocks!)

    InitZero

  • Isn't that what quotas are for? ;-)
  • I'm no expert, but I can think of a couple reasons offhand why you'd want to split 1 drive up into a bunch of partitions...

    first off, for security purposes. among other things, setting the 'nosuid' flag in /etc/fstab for certain partitions (like /tmp) can be kinda handy...just in case.

    second of all, although of course multiple harddrives would be a better solution, there still are cases where a big screwup causes corruption of a particular partition, rather than the whole filesystem. i'd rather take the time to make multiple partitions, and lose my /opt when i mess something up, than lose everything.

    ...just my $.02
  • For single user systems I agree with your suggestsions. There is no need to get into sophisticated partitioning schemes. For multi-user systems and servers, more consideration should be given to the partitions.
  • I have one 15M /boot partition, one 128M swap partition and the rest of the drive (/) is reiserfs at it's max capacity. There's no resizing, no muss, no fuss. I can't believe that more people don't do this. I've never had a problem at all!!! Why the need for 20 different partitions just for one OS? Why would you want to have to screw around with links and stuff when /var/log is full. What a hassle. -Pete
  • It depends....it's too difficult to predict some things. For example, I find it hard to predict log file size reliabley to be able to have enough disk space at all times on it. Plus if it's a webserver, you never know when your traffic will just jump up 100 % (creating a equal jump in the web server log file size). I guess what it all boils down to is make sure you have room to grow in all file systems and use quotas for your /home directory and you ought to be ok for the most part. Of course, if YOU KNOW you aren't going to have enough space, you better be shoppin for drives. Better to have at least double your needs to start off with rather then less.

  • I'm an on-off linux experimenter. I dual boot with windows. Sometimes I find myself using linux for months, then getting back to windows for a while, for some specialized apps.

    My current setup is like this;
    /boot ~15megs
    /win ~12gigs
    / ~12gigs
    swap ~200megs

    pretty simple basic dual-boot that takes care of lilo problems. I back up important data to cdr on occasion.

    What is the purpose of having /, /var, /opt, etc. as separate partitions? Is there a performance improvement due to arranging them on the disk platter in a certain way?

    Linux gurus, explain! :-) thanks.

  • I can understand putting /var and /tmp on separate partitions to control their size, and avoid everything dying when your logs get huge.

    The same maybe for /home, if you're going to have many users (ISP style environment).

    While we're at it, you didn't say what the machines are supposed to be used for... Are you doing another slashdot, or another geocities?
    I've noticed that a lot on slashdot recently, asking a question like this without giving even a clue to the environment it's in... What kind of an answer do you expect?

    /boot is obvious if you need it, but you probably won't (what with newer versions of lilo supporting big disks).

    What do you expect to gain from sticking everything in separate partitions? My experience has always been that you will run out of space on the wrong partition, so for personal machines I only have a single root partition.
  • I used a modified version of this. I feel it is a good template. http://www.valinux.com/products/parts/partition.ht ml

  • first off, for security purposes.

    I'm taking these nodes to be workstations for individual users. These are, for the most part, not shared machines. Thus, while I agree with you in theory, in this practical case, you security concerns are moot.

    a big screwup causes corruption of a particular partition

    Good point though I can't think of a non-physical problem that would screw up a single partition given the single harddrive.

    I'm not trying to be negative. I've split data across many partitions on single drives myself. I just want to know if I've been wasting my time.

    InitZero

  • Yep me too! On my laptop I simply have /boot and / along with some swap. I keep all my transient data on the server though.

    On my home server machine I have 128 M swap, 16 M /boot, 2 G for / and then a separate partion ("/p2") of the rest of the drive where I put the home directories (/p2/home/...) and my equivalent to /usr/local (/p2/local/...). Which means I can upgrade the OS using my preferred technique (format partition, install from scratch).

    Got a few production servers at work and I've followed the same pattern here. Once you're using RAID you've lost any physical meaning to your partitions anyway, so I can't see a performance gain - at least how to determine it without a lot of testing.

  • Of course, since you only have one drive, you may want to take the easy way out. Why not have one and only one partition: root. If you will never fill the full 20 gig and these are workstations and not servers, why have the headache?

    One reason might be to prevent your logfiles from filling up all the space that your database or other user apps use, for example. If someone's running a DoS against you to generate huge logfiles, you could find yourself unable to write to that partition.

    Separating partitions like /var, which have this potential, can increase the robustness of your system. Do I do this? No, because it's just too much of a pain, but the poster might wish to if he is logging from 50+ boxes, as he says he is.

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close