Linux partition scheme

http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/s2-diskpartrecommend-x86.html#sn-partitioning-advice

8.16.5. Recommended Partitioning Scheme

8.16.5.1. x86, AMD64, and Intel 64 systems

Unless you have a reason for doing otherwise, we recommend that you create the following partitions for x86, AMD64, and Intel 64 systems:

• A swap partition
• A /boot partition
• A / partition

• A swap partition (at least 256 MB) — swap partitions are used to support virtual memory. In other words, data is written to a swap partition when there is not enough RAM to store the data your system is processing.
  In years past, the recommended amount of swap space increased linearly with the amount of RAM in the system. But because the amount of memory in modern systems has increased into the hundreds of gigabytes, it is now recognized that the amount of swap space that a system needs is a function of the memory workload running on that system. However, given that swap space is usually designated at install time, and that it can be difficult to determine beforehand the memory workload of a system, we recommend determining system swap using the following table.

  Table 8.3. Recommended System Swap Space

  Amount of RAM in the System	Recommended Amount of Swap Space
  4GB of RAM or less	a minimum of 2GB of swap space
  4GB to 16GB of RAM	a minimum of 4GB of swap space
  16GB to 64GB of RAM	a minimum of 8GB of swap space
  64GB to 256GB of RAM	a minimum of 16GB of swap space
  256GB to 512GB of RAM	a minimum of 32GB of swap space

  
  
  Note that you can obtain better performance by distributing swap space over multiple storage devices, particularly on systems with fast drives, controllers, and interfaces.

• A /boot/ partition (250 MB)

  The partition mounted on /boot/ contains the operating system kernel (which allows your system to boot Fedora), along with files used during the bootstrap process. For most users, a 250 MB boot partition is sufficient.

  Important — Supported file systems

  The GRUB bootloader in Fedora 15 supports only the ext2, ext3, and ext4 (recommended) file systems. You cannot use any other file system for /boot, such as Btrfs, XFS, or VFAT.

  Note

  If your hard drive is more than 1024 cylinders (and your system was manufactured more than two years ago), you may need to create a /boot/ partition if you want the / (root) partition to use all of the remaining space on your hard drive.

  Note

  If you have a RAID card, be aware that some BIOSes do not support booting from the RAID card. In cases such as these, the /boot/ partition must be created on a partition outside of the RAID array, such as on a separate hard drive.

• A root partition (3.0 GB - 5.0 GB)

  This is where "/" (the root directory) is located. In this setup, all files (except those stored in /boot) are on the root partition.
  A 3.0 GB partition allows you to install a minimal installation, while a 5.0 GB root partition lets you perform a full installation, choosing all package groups.

  Root and /root

  The / (or root) partition is the top of the directory structure. The /root directory/root (sometimes pronounced "slash-root") directory is the home directory of the user account for system administration.

Many systems have more partitions than the minimum listed above. Choose partitions based on your particular system needs. For example, consider creating a separate /home partition on systems that store user data. Refer to Section 8.16.5.1.1, “Advice on Partitions” for more information.

If you create many partitions instead of one large / partition, upgrades become easier. Refer to the description of the Edit option in Section 8.16, “ Creating a Custom Layout or Modifying the Default Layout ” for more information.

The following table summarizes minimum partition sizes for the partitions containing the listed directories. You do not have to make a separate partition for each of these directories. For instance, if the partition containing /foo must be at least 500 MB, and you do not make a separate /foo partition, then the / (root) partition must be at least 500 MB.

Table 8.4. Minimum partition sizes

Directory	Minimum size
/	250 MB
/usr	250 MB, but avoid placing this on a separate partition
/tmp	50 MB
/var	384 MB
/home	100 MB
/boot	250 MB

Leave Excess Capacity Unallocated

Only assign storage capacity to those partitions you require immediately. You may allocate free space at any time, to meet needs as they occur. To learn about a more flexible method for storage management, refer to Appendix D, Understanding LVM.

If you are not sure how best to configure the partitions for your computer, accept the default partition layout.

8.16.5.1.1. Advice on Partitions

Optimal partition setup depends on the usage for the Linux system in question. The following tips may help you decide how to allocate your disk space.

• If you expect that you or other users will store data on the system, create a separate partition for the /home directory within a volume group. With a separate /home partition, you may upgrade or reinstall Fedora without erasing user data files.
• Consider encrypting any partitions that might contain sensitive data. Encryption prevents unauthorized people from accessing the data on the partitions, even if they have access to the physical storage device. In most cases, you should at least encrypt the /home partition.
• Each kernel installed on your system requires approximately 10 MB on the /boot partition. Unless you plan to install a great many kernels, the default partition size of 250 MB for /boot should suffice.

  Important — Supported file systems

  The GRUB bootloader in Fedora 15 supports only the ext2, ext3, and ext4 (recommended) file systems. You cannot use any other file system for /boot, such as Btrfs, XFS, or VFAT.
• The /var directory holds content for a number of applications, including the Apache web server. It also is used to store downloaded update packages on a temporary basis. Ensure that the partition containing the /var directory has enough space to download pending updates and hold your other content.

  Warning

  The PackageKit update software downloads updated packages to /var/cache/yum/ by default. If you partition the system manually, and create a separate /var/ partition, be sure to create the partition large enough (3.0 GB or more) to download package updates.
• The /usr directory holds the majority of software content on a Fedora system. For an installation of the default set of software, allocate at least 4 GB of space. If you are a software developer or plan to use your Fedora system to learn software development skills, you may want to at least double this allocation.

  Do not place /usr on a separate partition

  If /usr is on a separate partition from /, the boot process becomes much more complex, and in some situations (like installations on iSCSI drives), might not work at all.
• Consider leaving a portion of the space in an LVM volume group unallocated. This unallocated space gives you flexibility if your space requirements change but you do not wish to remove data from other partitions to reallocate storage.
• If you separate subdirectories into partitions, you can retain content in those subdirectories if you decide to install a new version of Fedora over your current system. For instance, if you intend to run a MySQL database in /var/lib/mysql, make a separate partition for that directory in case you need to reinstall later.

The following table is a possible partition setup for a system with a single, new 80 GB hard disk and 1 GB of RAM. Note that approximately 10 GB of the volume group is unallocated to allow for future growth.

Example Usage

This setup is not optimal for all use cases.

Example 8.1. Example partition setup

Table 8.5. Example partition setup

Partition	Size and type
/boot	250 MB ext3 partition
swap	2 GB swap
LVM physical volume	Remaining space, as one LVM volume group

The physical volume is assigned to the default volume group and divided into the following logical volumes:

Table 8.6. Example partition setup: LVM physical volume

Partition	Size and type
/	13 GB ext4
/var	4 GB ext4
/home	50 GB ext4

http://unix.stackexchange.com/questions/37720/best-disk-partitioning-scheme-for-a-linux-based-developer-machine

On our internal developement virtual machines we use three partitions:

1. /root partition - housing mostly static operating system stuff
2. /var partition - for all dynamic data
3. /home partition - this is where development takes place with the user accounts of the developers

The reason to separate the partitions is to avoid a system halt due to full filesystem. If /home is full - does not matter. No running processes are affected. Delete something, enlarge online and continue.

/ should not change much (the only exception is /tmp - but files there are usually never big).

/var is the place where /var/tmp and all other "live" data resides (including /var/log). A full/var/log is still the number one reason for system/application failures, so /var has to be big enough and there has to be a warning in time when space is becoming sparse there...

On physical machines, where disk space does not matter that much, we divide up additional "partitions" (mostly LVs), including: /var, /var/tmp, /var/log, /tmp, /boot, ... but these are production machines, where uptime matters.

http://unix.stackexchange.com/questions/34744/partitioning-for-web-servers

1) I'd strongly recommend that you use LVM2 (if you can in CentOS, which I'm not too sure, though). If you can, it will be very helpful when you reach that point where partition /var is 99% usage and/home is 1%. You may never use its resizing features, but it really gives (at least to me) peace of mind. One little warning: If you use LVM2 you won't be able to have the /boot folder inside the LVM2 "Volume". It has to be in a separate partition outside the LVM system as a regular partition (at least, that's my belief as of today, Thursday March 22, 2012)

2) I always create, at least, 4 partitions to mount

/
/boot
/var
/home

Sometimes /tmp as well (and swap, but I'm not really counting that one)

/var and /tmp can grow in a kind of uncontrolled way (log files, media going up and down the server, bad stuff). They shouldn't, but they can.

/home because you may want to store some tricks, documents, ideas... stuff that you found when your server was running and if your system blows up, you may want to have a chance of recovering those.

http://linuxmafia.com/~karsten/Linux/FAQs/partition.html

Basic recommendation

    /                   64 - 750+ MiB      (Stock kernel modules are ~100 MiB +)
    /tmp                50 MiB - 2+ GiB     (1 GiB+ to 18 GiB for some CDROM/DVD burning SW)
    /var                4+ GiB             (3 GiB + for Debian users)
    /usr                8 - 16  GiB        (10+ for a generous install)
    /usr/local          1 - 2+  GiB        (Really depends on what you put there)
    /home               remainder          (Music/video generally biggest)

As of Debian 5.0, minimum installation disk requirements are about 500 MiB, with 5 GiB recommended for a desktop install. I'd bump that up to 12-16 GiB, and maybe even 20 GiB allowing for ample space to grow your system data usage. Realize that you're likely going to install more software over time, that that software may grow in size, and and that features you're not directly aware of such as internationalization, documentation, kernel modules, OpenOffice.org modules, and other back-office stuff can account for a surprising amount of space.

Why Partition at All?

A question that's frequently asked is what the use of partitioning is in the first place. After all, doesn't partitioning date back to times when a disk of a hundred, or even tens, of mebibytes, was considered large? Yes, somewhat, but there are other reasons:

• Reliability: Disk corruption tends to be specific to a given partition. By subsetting your disk(s), you're reducing the amount of space that's going to be affected by any given disk error. If part of your disk goes south, you'll still likely have most of your system available.
• Containment: It's very helpful to contain runaway processes. By restricting /tmp and /var to their own partitions, you're pretty sure to have space available on the root filesystem or /home even if some process goes crazy with its tempfiles, or your system logs fill up.
• Security and privileges: By separating out your partitions, you can assign permissions appropriately. As a matter of course, only root and /udev (generally handled automatcially) need be mounted with device permissions, it and /usr are the only partitions needing SUID permissions, /usr can be mounted read-only for the most part, etc. While these permissions can be changed without unmounting a filesystem, they may prevent some system exploits, and will almost certainly keep you from shooting yourself in the foot at some point.
• Backups: many backup utilities are partition-based, or can be instructed to follow (or restrict themselves to) partition boundaries. Separating system partitions (root, /boot, /etc, /usr, /var) from locally managed (/usr/local, /home) and temporary (/tmp) makes system upgrades and migrations easier to handle as well.
• Management: With separate partitions, it's possible to back up one partition to another while performing administrative tasks. This is useful should, say, you need to convert between non-interchangeable filesystem types. If possible, having two large filesytems of comperable size may be helpful for on-system management.
• Overdoing it: yes, you can have too many partitions. Beyond a point, partitioning creates more issues -- you're subdividing your system, cutting into usable space, and adding complexity -- than you're solving. For small systems (< 500 MiB), root, /usr, and swap may be all you need, with /tmp, /var, and /home symlinked under /usr. By priority, I'd create: root, swap, /usr, /boot, /tmp, /var, /home, and /usr/local as separate filesystems, with increasing space.

Among other considerations you might want to take into account are:

• SSD: Solid-state "flash" drives. These are starting to appear as primary storage on smaller/portable devices, and as ancillary or high-speed storage on desktop and server hardware. Ideally the OS itself would allocate this as a persistant, high-speed cached storage fronting disk, but how this works out is yet to be seen. For the moment, treat as expensive but very fast disk with no seek cost. If you have both SSD and rotational media on the same system, put core OS and swap on SSD. /home, particularly media files, may go on rotational media.
• Removable storage: Increasingly removeable drives of various sorts are being used with systems. Generally these are managed through automated tools either at the desktop or system level through udev, hotplug, and related tools. None of these solutions appeals to me as being particularly elegant, but then again, this is Linux we're talking about ;-)
• Networked storage: Though not part of the local partitioning scheme, rationally managing networked storage locations is another part of your storage puzzle. With home LAN/SAN solutions, enterprise requirements, and online storage solutions providers, this becomes yet another management issue.