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
swappartition - A
/bootpartition - 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
The partition mounted on/boot/partition (250 MB)/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
This is where "rootpartition (3.0 GB - 5.0 GB)/" (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
/rootThe/(or root) partition is the top of the directory structure. The/rootdirectory/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
/homedirectory within a volume group. With a separate/homepartition, 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
/homepartition. - Each kernel installed on your system requires approximately 10 MB on the
/bootpartition. Unless you plan to install a great many kernels, the default partition size of 250 MB for/bootshould 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
/vardirectory 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/vardirectory 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
/usrdirectory 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
/usron a separate partitionIf/usris 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:
/rootpartition - housing mostly static operating system stuff/varpartition - for all dynamic data/homepartition - 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.
