Debian Planet

Welcome to Debian Planet


All your woody are (not quite, but very very very soon) belong to us.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers' Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You're not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International



  • EsDebian


  • DebianWorld


  • MaximumDebian


  • DebianUsers


  • Debian-BR


  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you've written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.


    DP is sponsored by Xinit Systems and

    Domains paid for and hosted by

    Buy your Debian merchandise at

    Who's Online

    There are currently, 91 guest(s) and 5 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.

    Partitioning tips
    Contributed by Anonymous on Tuesday, April 02 @ 19:24:07 BST

    Ask Debianplanet
    I plan on running Debian on a new desktop and have come to a question I have yet to see a definative answer on yet. How should I partition the hard disk? Is it worth creating multiple partitions on a desktop system with 2 or 3 users? whats the best way to do it? Assume I'll have a 60 GB drive, and possibly want to add another soon, how would I maximize the benifits or multiple partitions (if they are that important at all) without having space issues down the road?

    Rob: LVM.

    Related Links

  • More about Ask Debianplanet
  • News by rob

    Most read story about Ask Debianplanet:
    XFree86 4.2.0

    Last news about Ask Debianplanet:

    Printer Friendly Page  Send this Story to a Friend
  • "Partitioning tips" | Login/Create Account | 41 comments

    The comments are owned by the poster. We aren't responsible for their content.

    Re: Partitioning tips (Score: 2, Interesting)
    by Anonymous on Tuesday, April 02 @ 19:52:53 BST

    Wow, I didn't know about LVM. Very interresting. Thanks. The question still remains, how real are the benefits of having seperate partitions (or LVM logical volumes) on only one disk?

    [ Reply ]

    Re: Partitioning tips (Score: 2, Interesting)
    by Anonymous on Tuesday, April 02 @ 20:33:05 BST

    I used to split things up to cut down on fsck times. Now that I use journaling FS's it's not that much of a problem.

    The reasons people split partitions up is usually one of the following:

    1) Security. Mounting things read only can prevent something like a bad file permission from getting exploited on a multiuser system. In a typical setup, only /tmp, /var and /home really ought to *have* to be writable unless you have some stuff under /usr/share or similar.

    2) possible fsck/disk or filesystem-related security problems. Not having /var on the same partition as /boot or /sbin might be nice if you have a nasty filesystem error and get some file crosslinking with your kernel image or an important binary. Also, if you aren't running a journaled FS, it'll save you time on reboot not having to check a filesystem (if you mount it ro, that is). It also may be possible; however slim, for someone to exploit a security hole to gain access to another file on a filesystem they're not supposed to see. Of course, this requires that they be able to create or modify data on the same filesystem as the file they are attempting to access.

    3) Resource management: You dont want a user filling up /home to prevent your system from writing logs in /var. Conversly, you don't want an out of control daemon filling up /var and leaving you no space in /home! Granted, there are generally a lot of blocks that are superuser-reserved to prevent this sort of problem, but It's still a concern. Quotas can help here also.

    All that being said, on relatively personal machines with only a couple users, I usually partition /boot seperately and leave the rest to LVM so I can grow the fs. On larger multiuser machines I manage, I usually parititon /, /var, and /home seperately; mostly because of the security concerns. I don't use LVM on these either. I figure they're backed up to another HDD and/or tape, so if I do need to grow a filesystem, i can just do it manually (or some of them have hardware raid5 that can grow itself, too)


    [ Reply ]

    Re: Partitioning tips (Score: 2, Interesting)
    by ChuukNoris on Wednesday, April 03 @ 21:11:23 BST
    (User Info)

    Just to expound on points #1 and #2 above:

    One of the major reasons to have different partitions, that I haven't seen explicitly mentioned here, is that it really helps with system security. Indeed, mounting /usr (and as many other partitions as possible) read only is one of the best things you can do for your system. Not only does it prevent file permission problems (as GoRK rightfully mentioned), but there is probably a good chance that it will stop script kiddies from easily taking over your entire system. I only say this because I'm expecting the average h4x0r or worm not to know how to deal with such things. Of course, this may not be a valid assumption.

    More importantly, there are an entire class of vulnerabilities that can be prevented by keeping things on different partitions. To oversimplify a bit, most of the `race conditions' that one hears about can be thawarted by partitioning.

    Here's why. If some program has an exploitable race condition, it can often be exploited by making a hard link (with the `ln' command) to some other file, say in /etc. Then the malicious user can overwrite, say, your /etc/passwd file, at best causing a denial of service attack (as no one will be able to log in), at worst gaining root access. If /tmp is on it's own parition, however, it can only be used to overwrite other files in /tmp.

    Every directory that users (i.e. not root) have write access to should be on a different partition than all of your programs (/usr, /bin, /sbin ...) and configuration files (/etc). This, combined with mounting everything possible as read-only, is the first step to really securing a UNIX system.

    (Incidently, if you do decide to mount /usr as read only, check out this

    for information on how to make apt automatically
    re-mount it rw and ro again.)

    Keeping everything on seperate partitions will also allow you to use some of the more paranoid mounting flags, such as nodev and nosuid. Since there's *usually* no reason for anyone to be creating devices anywhere except /dev, and almost never a reason for there to be setuid binaries in /tmp or /var, you can make it even more difficult for someone to break into your system. Note that many script kiddy ready exploit scripts on the Internet try to do things like create a setuid root shell in /tmp. Also, be very careful about settings these flags-- some programs do need devices in wierd places.

    I realize after rereading what I've written that
    it's not really oriented twoard the new UNIX user or admin. Some of the topics I've only briefly glossed over, such as race conditions, can get
    pretty complex and there are much better explinations of how they work already out there.
    That said, as far as a home system goes, it really depends on how secure you want to be vs. ease of use. All of this paritioning does tend to make life a pain in the ass when you need to download that 4GB file but only have 3.5 GB availabile in /home and 3.5 GB available in /var 🙂 But for a server it's invaluable.


    [ Reply ]

    Re: Partitioning tips (Score: 2, Interesting)
    by itsafire on Tuesday, April 02 @ 20:34:48 BST
    (User Info)

    In case of a desktop installation, there will be probably no need to have multiple partitions, besides root and swap. Things get different, if you plan on using server applications.

    Database servers are commonly not very happy, if they run out of disc space. In this case it may be wise to donate a separate partition to this service. In this case you should use /var as a mountpoint since all servers will keep their data somewhere in /var

    Some applications tend to produce a lot of data, like logfiles or other data (ie. squid http cache). To ensure this data won't fill up your filesystem, you can use a partition to limit this possible fault to a special directory only (ie. /var/spool/squid)

    For chosing the right size of partitions LVM comes in handy.

    If you plan on using a single partition and this partition will be quite big (>60GB), you should consider using one of the new filesystems like xfs or jfs to speed up filesystem checks on crashes.

    [ Reply ]

    Re: Partitioning tips (Score: 1, Informative)
    by Anonymous on Tuesday, April 02 @ 21:03:54 BST

    I think that having multiple partitions, regardless of the number of users on the system, is very important. Since this system is not going to be mission-critical, I'd recommend at least having root, boot, and home partitions. My school of thought is this:

    If you mess up your system really badly, you can format your root partition and re-install the OS. When the OS has been installed, mount the other partitions (you'll have to move boot), and your users' data will still be in their home directories, and any customized kernel that you've compiled will still be there, so you won't need to recompile to get your soundcard working or something (one problem-- your modules won't be in /lib/modules anymore). I like using the kernel package to manage my kernels, and save the builds in /home, so if I need to re-install, after boot I can install the packages and be done with it.

    [ Reply ]

    Re: Partitioning tips (Score: 1, Informative)
    by Anonymous on Tuesday, April 02 @ 23:10:55 BST

    if possible put your data on a seperate _disk_ then your system, if you lose a disk, you're less screwed.

    it's good to have a running system if you loose your data-disk and it's good to have a disk with data if your system-disk fails (ESR said so in his 'The perfect Unix/Linux workstation', or similair/whatever).

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Wednesday, April 03 @ 01:57:19 BST

    Er... I think I'd go with RAID 1/mirror before doing that...

    [ Reply ]

    Re: Partitioning tips (Score: 1, Funny)
    by Anonymous on Wednesday, April 03 @ 03:52:07 BST

    Naw, back it up to a server. Any true geek needs a server anyhow, and it's cheaper to just use that than buy another disk. 😉

    [ Reply ]

    Re: Partitioning tips (Score: 2, Insighful)
    by d8A90n ( on Wednesday, April 03 @ 00:14:20 BST
    (User Info)

    What is LVM? I've looked on their website but I still don't quite understand what it's supposed to do? Is it some kind of partition magic for linux?

    [ Reply ]

    LVM= (Score: 1, Informative)
    by Anonymous on Wednesday, April 03 @ 02:44:06 BST

    Logical Volume Manager. It allows you to create a logical volume/s out of one or more disks. Have to admit, I've not used it under Linux, but I assume it's the same as with other *nices... it allows features such as mirroring one disk to another (to allow for hardware failures), concatenating disks together (to make two 40GB disks seem like one 80GB disk, in case you need an 80GB file, or 80GB filesystem), RAID5, etc.

    [ Reply ]

    Re: LVM= (Score: 0)
    by Anonymous on Monday, April 08 @ 15:08:11 BST

    It alow for example creation of virtual partition on multiple disk, resizing those partition without rebooting the os nor unmounting the partition (in most case and with a correct fs like reiserfs)

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Saturday, April 06 @ 17:57:49 BST

    It helps for some things:

    - Different Mount Options (noexec,ro,nsuid, ...)

    - avoids /home filling up system partitions /var/run

    - easier backup

    - faster recover if only haf of the disk is mounted rw

    But generally it is quite anoying, even using LVM on a single disk is not that useful.

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Tuesday, April 02 @ 20:08:10 BST


    [ Reply ]

    Re: Partitioning tips (Score: 1, Interesting)
    by Anonymous on Tuesday, April 02 @ 23:08:07 BST

    I'd suggest you don't forget a /home partition. That saved my life several times. The first thing you want to do is keep your personal stuff and work away from your root partition. If something goes wrong with your installed system you still have your beloved work safe and secure.

    [ Reply ]

    Re: EVMS !! (Score: 0)
    by Anonymous on Wednesday, April 03 @ 22:06:56 BST

    This is the way to go. Use EVMS.

    [ Reply ]

    Re: Partitioning tips (Score: 2, Informative)
    by d8A90n ( on Wednesday, April 03 @ 00:25:54 BST
    (User Info)

    For a desktop debian user (no squid proxy, no large DB or http servers) here's my tip:

    /boot - 15mb

    /var - 400mb

    / - 4GB (mostly for /usr)

    /home - all the rest

    • Most of your files will go in /home which is why it should be the biggest. I use my entire 20BG hd.

    • /boot is essential.You could go for 5 or 10mb, but if you recompile your kernel often and don't want to clean too often 15 is a good bet.

    • /var... I didn't believe it was necessary until pump filled my hard drive with error messages in /var. Usually for a home user people recommend 200mb... but with apt-get, if you're like me and and don't want to use auto-clean and forget to run apt-get clean often, it comes in handy.

    • / contains everything else including /usr which is probably what will take most of the space. With only applications, 2BG is enough but if you plan on installing a few games (either old loki games or newer ones) you'll need that much, and maybe more. I have 4GB with a normal number of apps, only SimCity3k installed and I'm a bit over 2GB.

    [ Reply ]

    Re: Partitioning tips (Score: 2, Insighful)
    by xm (mike(a) on Wednesday, April 03 @ 06:18:46 BST
    (User Info)

    Close, but no cigar. For drives larger than 8 or 9Gb, I use (order *is* important):

    / 256M
    [swap] 512M
    /var 512M
    /usr 4096M
    /home [remainder of free space]
    /tmp [swapfs]

    A separate /boot partition is redundant if / is set up properly. You want / to be as small as humanly possible to help with disaster recovery, etc. Certainly, putting all of /usr in the root partition is a bad, bad idea.

    You're correct about /home and /var, but if I have the space, I prefer to err on the side of caution - a 512M /var partition will be very hard to fill up on a desktop, even after a big apt-get dist-upgrade.


    [ Reply ]

    Re: Partitioning tips (Score: 1)
    by Doc_Linux on Wednesday, April 03 @ 13:01:38 BST
    (User Info)

    Good start. I just finished building a new workstation that has a 60 gig drive. The partitions look like this:

    Filesystem Size Used Avail Use% Mounted on
    /dev/hda2 957M 42M 866M 5% /
    /dev/hda1 30M 5.4M 23M 19% /boot
    /dev/hda3 957M 130M 779M 15% /var
    /dev/hda5 3.8G 384M 3.1G 11% /usr
    /dev/hda6 1.9G 60k 1.7G 1% /usr/local
    /dev/hda8 463M 21k 439M 1% /tmp
    /dev/hda9 47G 531M 46G 2% /home

    I install a lot of things from source, hence a fairly large /usr/local. /tmp is quite big really, but I have bad habits 😉

    [ Reply ]

    Re: Partitioning tips (Score: 1)
    by Doc_Linux on Wednesday, April 03 @ 13:03:44 BST
    (User Info)

    Do'h - excuse the formatting 🙁

    /dev/hda2 957M 42M 866M 5% /

    /dev/hda1 30M 5.4M 23M 19% /boot

    /dev/hda3 957M 130M 779M 15% /var

    /dev/hda5 3.8G 384M 3.1G 11% /usr

    /dev/hda6 1.9G 60k 1.7G 1% /usr/local

    /dev/hda8 463M 21k 439M 1% /tmp

    /dev/hda9 47G 531M 46G 2% /home

    [ Reply ]

    Re: Partitioning tips (Score: 1)
    by d8A90n ( on Wednesday, April 03 @ 15:59:14 BST
    (User Info)

    Doh, forgot ram...

    Actually I do have a seperate /usr of 4GB... I just don't see the use of it :o!... for a home computer that is.

    For swap, here's my rule of thumb.

    If you have 64MB or less go add swap up to 128MB. If you have between 64 and 128 add swap to 256MB. If you have between 128 and 256 add swap to 396MB

    If you have 256 to 512 add only 100-50MB. If you have over 512, 20MB will do fine... you'll probably never use it anyways, even with staroffice, mozilla, konquer, KDE3, about 15 terms, licq, gimp, gnumeric, gnucash nautilus all opened at the same time. I have 512 or ram and never use my swap...

    [ Reply ]

    Re: Partitioning tips (Score: 1)
    by Doc_Linux on Thursday, April 04 @ 08:47:11 BST
    (User Info)

    I tend to find that even with 768M ram on my workstation, it'll swap 10-15 meg after a day or two's uptime. I always add around a gig of swap on this machine because disk is cheap & I'd rather have too much swap than not enough 😉

    [ Reply ]

    Re: Partitioning tips (Score: 2, Interesting)
    by Anonymous on Wednesday, April 03 @ 02:38:23 BST

    You forgot to mention swap; different people will tell you anything between 1xRAM and 3xRAM, so if you've got a 128MB box, anywhere between 128MB and 384MB swap is needed. I tend to go for around 2xRAM, myself.

    Of what's left, Sun recommend 1.5GB for /var on typical servers, and dump the rest into /. Of course, for linux, a seperate /boot is useful.

    In these days of huge hard drives, though, partitioning the drive is largely unnecessary. The reasons for doing it are:

    • swap needs its own partition
    • /boot needs to be at the start of the disk
    • /var can fill up too much
    • /home can fill up too much
    • /home/foo can take disk space away from /home/bar if they're on the same partition

    Of these, the swap and /boot arguments are valid; of the rest, can you honestly say that these will be a problem? If not, throw them all into / ... otherwise, you face the problem that /usr is full, /home/foo is full, but /home/bar is only 1% utilized.

    It's possible that /var will become a problem, so with a 60GB disk, throw a few GB towards /var, and sleep easily at night knowing that unwanted logs won't cause your machine to grind to a halt... unless the thought of losing the logs keeps you awake, of course!

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Wednesday, April 03 @ 08:58:25 BST

    Setting your swap space to 1x the ammount of RAM would be pointless. Swap space does not always act as extra RAM, until you exceed the amount of RAM in your system, especially on 2.4.x kernels. 2xRAM is often recommended, unless you have very little RAM in the system.

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Wednesday, April 03 @ 15:09:16 BST

    I thought that had all changed back again with the new VM so that it was closer to 2.2 for swap needs.

    I do tend to go with 2xRAM as a rule any more is a waste.


    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Thursday, April 04 @ 01:05:55 BST

    "2xRAM as a rule any more is a waste"

    At <$130 for a 80GB harddisk, harddiskspace is less than $2 per GB now. Go wild, spend those whopping $8 and give your box 4GB of swap, and your swap will be fast because of very little swap fragmentation, and always big enough (4G = 32 bit address space). Since a single user app can allocate up to approx 3.5GB of memory, having 4GB of swap will then guarantee to give that memory leaking alpha version gadget program the memory allocation error before any other more important program gets it.

    [ Reply ]

    Re: Partitioning tips (Score: 1, Interesting)
    by Anonymous on Wednesday, April 03 @ 03:49:53 BST

    There's no real need to bother with partitioning. That's more a throwback to the old days. Servers can use it, but more for data integrity in extreme cases, where it's not worth the effort on a wortkstation.

    Partitioning your drive on a workstation, you're going to run into the situation where you didn't allocate it right, and can't undo it. You can follow all the advice you want, but only you know if your machine will be mostly applications (3/4 GB games in /usr) or user data (MP3's/pr0n/homework).

    So far as I partition my 40GB machine, it's just (a) swap, at a massive 4GB, (b) /, the rest of the disk.

    You do not need a boot partition, since LILO can easily handle large hard-drives (assuming you're not running a very out-dated distro), and so can Grub.

    The reason I have such a big swap space is mostly just because I can. 😉 But for practical reasons, some of the stuff I do needs a lot more memory than I can afford in RAM, so it tends to help having the swap.

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Wednesday, April 03 @ 16:21:58 BST

    There's no real need to bother with partitioning. That's more a throwback to the old days. Servers can use it, but more for data integrity in extreme cases, where it's not worth the effort on a wortkstation.

    I hope what just happened to me happens to you. Because then I can laugh for many long hours. My system recently was hosed (wierd power outage + lots of ram + other stuff) because of massive fs corruption. I lost a fair bit of stuff (good old hexedit to the rescue..hexedit /dev/hda3 saved a few files). I essentially lost all of /, /usr/, and /var. But I still had all of my important stuff on /home (I recovered some stuff using hexedit and dd). When I did my reinstall, I just formatted /, /usr/, and /var leaving /home safe. If I did the one partition scheme, I probably would have lost all of /home, and I would have had to find a way to get 7GB (if it survived) off of my system with no large storage device around (I know, I'm getting a tape backup drive now!). Also, I noticed that I made /var too small and had to move it recently because it was filled up by htdig (it makes searching my documentation easy). Moral of the story: use more than one partion. Keep all important stuff away from the rest of the system, so have at least a / and /home partition. - unknown_lamer

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Thursday, April 04 @ 01:08:15 BST

    one word for you: ext3fs

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Thursday, April 04 @ 16:00:30 BST

    That is what caused half of my problems (I added an ext3 journal after the first power failure and then I crashed 10 minutes later) because fsck on the Debian install/rescue disk for woody (my old potato ones are no good anymore) has (or did they update to the fixed version?) a bug that made it crashed when you have an invalid journal on the device...but I'm running ext3 now and am happy (alsa 0.9beta12 forced me to crash and hit reset many a time before I realized that they wouldn't work...). The 5 second fsck on /home (15GB) is great! (of course, I don't normally crash...30 or 40 days uptime at a time is my usual). - unknown_lamer

    [ Reply ]

    Re: Partitioning tips - fragmentation (Score: 3, Insighful)
    by noviota on Wednesday, April 03 @ 08:43:17 BST
    (User Info)

    I've read all the posts here and they all fail to mention this (unless someone posts it while I write this). Your partitions become fragmented with a lot of read and writing (yes I know it won't get THAT fragmented, but still).

    For this I reccomend /var and /tmp are their own partitions.

    /boot is unneeded if you make a / partition and have /home and /usr on their own too.

    /home should be on its own partition just to protect the data, and for backing up it can be an ease of using dd with gzip and writing to cdrw.

    /usr/local if you use it for a lot of your own written software is also another good place to create a partition. Although I have known for it to be linked to /home/usrlocal/

    With this partition layout you can easily clear the system (partitions / /usr /var) and start again without loosing your own written software and user data.

    Sizing is a different issue altogether as is using multiple harddrives. Remember swap if its going to be used should be nearest the middle of the drive as possible as well as anything else that is going to be accessed a lot.

    My Partitioning for user machines usually end up like this:

    / 50 megs

    /usr Min 1 gig, Good 2 gigs.

    (Depends how much software you use, and if you compile much ie /usr/src)

    swap 120 (Although bigger, sometimes is better - all machines I had set up have 128 megs or less)

    /var MIN 256 Megs, Good 512 Megs, Excellect 1 gig

    /tmp Ditto as for var

    (Note tmp and var milliage may very if you are using databases, multimedia editing software)

    /usr/local (Personally i've often linked it to /home/usrlocal when compiled personal code needs to be looked after) Anything you need.. say 512 megs if you are unsure.

    /home as much as you can, i find symbolic links when you run out of space into this partition are sometimes life saving. (ie the time I ran out in /var when doing an apt-get)

    With a setup like this / and /usr can be mounted RO adding some protection. Although if you start using /usr/src that might get linked to /home or become its own partition.

    I am no expert in Linux and have only been using it for 4 or 5 years but this as my opinion works, and works well.

    [ Reply ]

    Re: Partitioning tips - fragmentation (Score: 0)
    by Anonymous on Wednesday, April 03 @ 15:24:10 BST

    /tmp only holds lockfiles so you doesnt need that much space there.

    [ Reply ]

    Re: Partitioning tips - fragmentation (Score: 1)
    by noviota on Thursday, April 04 @ 22:44:47 BST
    (User Info)

    Not always, I've used it in editing software and recording software before the data is converted into the final format that I want to store. But as I say, Your Milage May Very.

    [ Reply ]

    Re: Partitioning tips (Score: 1)
    by Britton on Wednesday, April 03 @ 09:56:51 BST
    (User Info)

    I have several questions to expletive this problem:

    As I know, on Linux you can have up to four primary partions, the others must be logical in extended partitions. Which parts should be on primary partitions and which should be in logical? What is the real difference in using primary or logical partition?

    [ Reply ]

    Re: Partitioning tips (Score: 1)
    by idiot on Wednesday, April 03 @ 10:53:45 BST
    (User Info)

    Speaking as somebody who has had to recover a lost partition table due to mangled windows installs *DON'T EVER USE EXTENDED PARTITIONS*.

    Primary partition tables are stored at the start of the disk, and are (relatively) easy to find and recreate, however extended partition tables are stored at some arbitary point, even using the wonderfull gpart it took me over a month of searching to find my /music partition.

    Oh, and keep a copy of your partition table *on paper* too. Mine's written on the side of the case in permanant marker.

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Wednesday, April 03 @ 11:23:20 BST

    That's not really a linux thing but more of a hardware restriction as far as i know. I beleive that is just a shortcoming of x86 systems.

    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Wednesday, April 03 @ 17:03:47 BST

    A hard disk can only be partitioned into four parts. That's an old restriction resulting from the original MS-DOS-Harddisk MBR definition.

    Then some people wanted to have more partitions, so they just modified MS-DOS enabling it to divide the partitions themselves again. These parts of a partition are called logical partition, the partition containing them are called extended partitions. An extended partition (which is also a sort of primary partition, but doesn't contain a filesystem but logical partitions) may have more than four logical partitions.

    Which one to choose is depends on whether your OS can boot from logical partitions. Lilo and Grub can boot from logical partitions, MS-DOS can't, never had Windows 95/98/... installed, but I expect any modern OS to be able to that.

    Just make a big extended partition and only use logical partitions.

    [ Reply ]

    Re: Partitioning tips (Score: 2, Insighful)
    by mr_jimmybob ( on Wednesday, April 03 @ 12:56:59 BST
    (User Info)

    Personally I find it very comfortable to have /usr/local/, /home and /opt on a partition other than the main one.

    This way you can just wipe out your linux to install another o update or whatever*. Backups are always advised anyway (but I never make them).

    Other considerations like, /var or /tmp on a different partition than / for security reasons (like filling the / file system,...) are not so important on personal computers.

    I would say stick it all in 1 partition + a swap (I use double the RAM size) on a home computer. I dont know why I always end up with loads of partitions ??.

    If we are talking about a server I would be a little more careful, and seperate /home, /var, /usr/local, /opt, /tmp, /boot and /usr. So you can make boot and / read only for security reasons. And isolate file corruption and disk usage.

    *note: This was a comon practice before I found debian. I would change my linux distro every now and then (slackware -> RedHat -> Mandrake -> debian). Have'nt found one better... yet!.

    [ Reply ]

    Re: Partitioning tips (Score: 1)
    by ironstorm on Wednesday, April 03 @ 22:55:10 BST
    (User Info)

    For my home system

    I use 1x the Machine's max possible RAM, so right

    now I have 256MB out a possible 768MB of real ram.

    My swap is 768MB

    / - 33% of the drive or 10 GB whichever is


    /home - rest of the drive - essential to have

    the user data on a seperate partition in case

    you need to rebuild.

    I use GRUB for my boot loader and don't bother

    with /boot, I've never really understood the

    value of it... (maybe if you boot different

    distros off the same kernel??)

    For a server:

    Similar to above, except potentially more swap

    depending on what you serve.

    And also a seperate /tmp and /var partitions so

    evil-doers can't DOS your box by log flooding,

    spam flooding, print queue flooding etc.

    (2 GB for each is plenty).


    [ Reply ]

    Re: Partitioning tips (Score: 0)
    by Anonymous on Saturday, April 06 @ 18:05:26 BST

    If you use LVM, it might be a good idea to eighter have a rescue partition, or a / partition stand alone, separated and not LVM managed, so restoring and rescue gets easier.

    It is generally a good idea to have a small alternative system on it's own partition, especially on servers.

    [ Reply ]

    Partitioning == Personal (Score: 1)
    by Pflipp on Thursday, April 04 @ 10:06:01 BST
    (User Info)

    I can remember that when I started with Debian, I asked the same question and got the same answers (that is, a whole lot of different answers). The answers would vary from the typical "you don't need to partition - except of course a boot, root, home and var partition" to "you must partition - make a swap partition".

    Point is that everyone eventually advised me to partition, but couldn't agree on how. I currently still have this system running, and the setup hasn't changed that much: a main disk of ~4Gb, and a few extra "toy" disks, now resp. ~1.6Gb and 800Mb. Because of all the different advises I got, I never partitioned it beyond swap space. I'm now quite happy neither to have this 4Gb space fragmented (all of it is used, mostly), nor to have used the other disks (I use it to store huge temporary data or e.g. an install of the HURD).

    I wouldn't know what to do for a larger disk, though.



    [ Reply ]

    Partitioning and backups (Score: 0)
    by Anonymous on Monday, April 08 @ 05:36:30 BST

    There are a lot of good comments here on partitioning. However, whatever partition scheme you choose has to be recoverable if you use backups.

    One thing to note. /usr/bin, /bin, /etc, /sbin, /usr/sbin, and /var (except /var/log) generally all have to be in sync. If they're not, then what will happen is that /var (which contains your debian package database) will think that some files are in place, but the other filesystems will not reflect that. So, imagine, the hypothetical situation where you do backups every sunday. On saturday night, right after you finished doing apt-get upgrade, the power goes out. When it comes back, something is funny with /var and you can't seem to get it back. When you restore that partition from backup, it's going to have in its database a hole bunch of crap that isn't true anymore, because /bin, /usr/bin, and /etc had been upgraded since that backup.

    The end result is that you will end up with *MAJOR* packaging confusion if you try and "apt-get upgrade". It is for this reason, and after having been seriously bitten by this, that I now partition as follows:





    By doing it this way, if I lose a partition, it doesn't matter which partition I lose. The restore will be in sync with the rest of the system.

    I seperate out /home and /var/log because I want to be able to do a complete install from scratch, if I need it, without losing the contents of my home directory. And /var/log is seperate because I've been network scanned before and had iptables output enough log data to cause / to fill up to 100%. When that happens a crash is imminant. So I set /var/log off on its own. If it fills up, the machine continues to run.

    But there are lots of good arguments for keeping /usr (for example) seperate so that you can mount it read only. I just recommend that you consider your backup & recovery strategy. I've been down the road of having to recover from an out of sync package dir and it can be very ugly.

    Good luck.

    [ Reply ]

    Based on: PHP-Nuke

    All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2000 by Debian Planet

    You can syndicate our news using the file backend.php.