One of the most critical decisions when installing Unix or Linux is how to best make use of limited disk space. Even with today's large hard disks, servers with hundreds of gigabytes of pictures, video, sound, database, and other data are common. Multi-user machines may require protection such as read-only partitions, disk quotas, etc.
Note that in this document I often say partition when technically I mean “file-system within a partition or slice”. Traditional Unix systems use slices, similar to DOS disk partitions. Each slice holds a filesystem, just like other OSes put filesystems into partitions. In the Unix world the terms partition and slice are unfortunately used inconsistently and sometimes interchangeably. Technically one should use the term storage volume instead.
There are many reasons for partitioning a large hard disk into several smaller partitions. For a home user with a single small-ish disk (today's large disks are tomorrow's small ones), a single Linux partition (plus swap, and maybe one for Windows in a dual-booted system) can be a reasonable choice. But multiple partitions provide additional safety and performance benefits, so I always prefer to create several partitions.
Until around 2008, there was very little to gain by not using a
However modern systems now support many “per-filesystem”
features, including security and robustness related
options such as preventing SUID (or even executables)
on data-only filesystems.
Today there is little to be gained by limiting the number of
filesystems you create to 5 or so, merely to satisfy a historical
Using logical volume management, one can create as many
filesystems as makes sense in a given situation.
Standard Unix systems are traditionally limited to 8 “slices” per disk, some of which have pre-defined uses. So standard Unix and Solaris disk layouts for many years worked around that limit by using best practices that didn't need more. However modern Unix systems (including Solaris 10) allows for a form of logical volume management, either with ZFS pools or by using Solaris Volume Management (SVM). So you shouldn't be afraid to define additional filesystems if they do make sense.
Of course just because you can partition a disk doesn't mean you should! The more partitions you create, the more there is to manage. If you guess wrong on the space required, you may have to later grow a partition (not the big deal it used to be). So you shouldn't make extra partitions unless you consider the extra work they create to be worth the additional protections they provide.
Here are some reasons to create extra partitions. If you choose not to follow some vendor-recommended standard disk layout, see which of these apply to your situation to decide which partitions to create:
/varthat users can easily fill with downloads, email, etc., are prime candidates for extra partitions. So are any other directories that might grow (directories for FTP uploads, database files, etc.).
/var/log), is a good choice for a separate partition.
/usr/share). Besides read-only, there are other
mountoptions that provide additional security:
acl, and others. Additional mount options can increase performance such as
*dump). Backups that span two or more tapes (or other media) can be problematic. For one thing, if you only have a single tape drive you can't automate the backups as a human must be there to change tapes. It is worth considering making enough partitions so that each one is small enough to fit onto a single backup tape.
fsck. If your disk is large it might take many minutes or longer to run
fsck, which will run automatically every so often. (It has been estimated that a full, maximum sized
ext4filesystem would take 119 years to run
fsckat today's speeds!) By partitioning a large drive into small partitions, the SA can stagger when such checks get done, so only a small part of the disk is (reasonably quickly) scanned at any one time. This greatly reduces the time needed to reboot after a system crash.
/bootpartition to hold the few files needed to boot the system, located near the beginning of the disk. This would include the kernel itself and the bootloader configuration file (e.g.
grub.cfg) amongst others. Many standard Linux distributions create
/bootpartitions “just in case” of older hardware. Some Unix distributions create a
/standalonepartition for similar reasons.
/boot partition may be needed on modern
This is because of an incompatibility between some
BIOS-based systems and modern EFI
gdisk), is usually 1 MiB in size, and doesn't need to be formatted (or assigned a mount point).
/bootpartition.) Depending on how many bootloaders, custom disk drivers, and other EFI software you plan on having, this partition should be at least 100 MiB; 300 MiB on multi-boot or experimental system would be fine.
Some reasons not to partition a disk include:
/etcshould never be separate partitions! At boot time, only
/is mounted initially. The
initprogram needs to access files in
/etcand the bootup scripts need access to commands in
/bin, which may depend on files in
/lib. Kernel modules required to complete the boot process are also kept in
Starting with Fedora 17, the bulk of the files historically found in
the root partition are now found in
(Apparently, Red Hat wants to redo the filesystem hierarchy standard.)
/lib, and other directories are now
just symlinks to
On such systems, the root partition can be smaller and
must be made larger.
It is probably best on such systems to simply not make
a separate partition.
/binrequire DLLs (“
.so” or shared object files) to work. These DLLs are often found in
/lib, but many are kept in
/usr/lib. So some commands won't work at boot time if
/usris a separate partition. On more recent systems, the system won't boot if
/usrisn't available! In
/bin, you may find (on older systems) some static1 versions of the more critical commands (the exact set and location varies with your flavor of Unix).
A problem with having many partitions is that you can run out of
space in one partition while another has excess capacity.
When the partition plan fails you may have to create a new plan,
backup all existing data in archives, re-format the disk, and
restore all the data.
Obviously this should be avoided if at all possible.
(Newer partitioning tools such as a live CD for
gparted makes it much easier to modify a disk
One commonly used technique to handle this situation is to use
symbolic links rather than re-partition.
Suppose for example you need to install a “nifty” word processor
/opt/nifty, only the
partition (which might be the root partition) doesn't have enough
/var partition does have extra space, you can
create a symlink to use it:
# mkdir /var/nifty; ln -s /var/nifty /opt/nifty
The problem with this approach is that too many such symlinks (sometimes referred to as a symlink farm) can make maintenance difficult. Quotas, backups, logging, and monitoring can all be affected. So adding such symlinks should be considered a “hack” and not a substitute for proper planning.
Modern Unix systems have virtual partitions called logical volumes or LVM. A logical volume should be thought of the same way traditional partitions and slices are. However, a volume can be composed of one or more physical partitions, possibly on separate drives. When a volume runs out of space, you can just add more disk space to an existing volume to grow it. Then any filesystem in that volume can be grown as well. Although logical volumes may be grown (or shrunk) much more easily than with traditional partitions, using volumes well still requires careful planning of both the logical partitions and the underlying physical partitions. (See about LVM for more information.)
A frequently asked question is how large should the
XYZ partition be?
Unfortunately there is no simple answer.
Consider a partition for
This needs to be sized to hold your logging data.
But how much data is stored?
If you have a central log server (“loghost”) you may not store
any log data on some other host.
Otherwise you may need to store only a little log data (say for
a printer server, anonymous FTP server,
or a static content web server).
But if this host is your central log server or if you don't have
a central log server and plan to keep 6 months of log data on-line,
you will need a lot more space than a host that only keeps 1-4 days
of log data.
So the size might be zero, less than 50 megabytes, or more than
10 gigabytes (or more; consider Apache access logs on a busy server).
Other partitions have similar considerations. You may need no separate partition at all, a very small one, or a huge one. If you have a separate partition for your database files, how much data do you plan to keep on-line? For a web server's files, is this a home user's hobby web server, or a training site with gigabytes of video clips? If you don't have a separate partition to hold crash dumps these end up in the swap partition, so that must be at least as big as your physical RAM and should be more. (This is needed to support hibernate and crash dumps too; the system needs to store a complete copy of the physical memory, in addition to whatever swap space is already in use.) To support hibernation, Red Hat recommends twice the amount of physical RAM for RHEL7. (For a home PC or classroom computer, you probably don't use much if any swap space normally, so you could probably configure less than that.)
Consider sizing partitions on a mail server.
The critical partition will be the one holding the user's
This may be stored in mailbox files in
or within the users' home directories.
Or even elsewhere in a database.
You need to estimate how much email will be kept on-line by
your users, and also allow enough space for “spam” or
a sudden burst of email traffic (or storage over a break
between semesters, when faculty rarely log in to read email).
A good guideline might be to use the same size limits per user
as some other email servers, such as Yahoo! mail or Google's
(If you can afford such large disks as Google.)
So, how large is the sum of your mailbox sizes?
Whatever it is, add sufficient space for growth and
multiple by the expected number of users.
At HCC, it might be reasonable to expect
per student, and 100,000 students (counting current, future,
and past students), or one TiB total.
If using some sort of LVM, it is usually not difficult to grow and shrink partitions later so there is little reason to worry about getting the size wrong. Still you should be able to make a reasonable estimate on the initial size of your partitions:
fedora.redhat.com), for partition / filesystem sizes required or recommended for various applications. For example, the swap partition should be at least as large as the amount of physical memory to support features such as hibernation and crash dump analysis. VMware recommends making the
/tmpfilesystem at least one and a half times the amount of virtual memory on your system. If running a database service, check the website (e.g., Oracle) for sizing recommendations.
/bootpartition it only needs to hold the OS image file(s) and boot loader file(s). Each bootable OS may only require 20-30 megabytes. So if you have only two OS images (the default for Fedora) you need less than 50 megabytes. On the other hand if you (like me) like to play around with different kernel configurations you may have 3 or 4 such image files. (Not forgetting the initial RAM disk image as well.) In such a case, or with larger kernel images, you may want over 100 megabytes for this partition.
/optpartition? If not any software installed there goes into the root partition. That can be as much as 12 gigabytes or more. On the other hand if you have separate partitions for
/var, etc., then the root partition can be quite small especially for a dedicated purpose server (that has no GUI and minimal software installed).
ducommand to see how much space is used for various directories.
/(the root partition), etc.
A final consideration is that there are modern alternatives to per server disks (or DAS). Using storage technologies such as NAS and SAN may mean your servers have no disks or just a small disk for booting only. Even with these technologies you still need to plan the number and purpose of filesystems. Organizing your storage well depends on available budget, technology, and local expertise.
If you plan to use Solaris “live upgrade”, you must duplicate
all slices that contain files added by the installer/patch
If you use mirrored disks there is no problem but on a single disk
you must either keep all system standard paths on the root slice or
Thus, best advice is to not sub-partition any standard paths in
It is okay to create new directories such as
and make those separate slices.
The best advice today is to keep the boot disk small and simple, using a standard layout. (But not the default layout for Solaris 10, it is known to not work as of 4/2008 for most disks!) Use other disks (or use a SAN or NAS if possible) for additional filesystems as needed. Keep in mind the max number of partitions possible on a disk for a given OS.
If you only have one disk (possibly because you're using hardware RAID), the most flexible disk map will reserve one slice/partition for LVM. Then you can create additional filesystems later as needed without re-formatting the disk.
Tools for partitioning DOS/MBR disks include
fdisk but with a curses UI),
fdisk replacement that
gdisk (modern replacements that understand
format, Disk Druid,
fips.exe (a DOS program, used to split a FAT
partition into two;
you can then delete the 2nd partition and use the freed space for Linux),
and Partition Magic.
A live CD/USB for this (works with
NFTS but not LVM) is
Only a few of those tools have been updated to support
However you can use
sgdisk for such disks.
If the partition table on a disk gets corrupted (and you don't have a backup)
you can use
gpart (not [g]parted) to scan a disk
and guess the partition map.
This be then be written to the MBR to recover the disk.
Choosing number and type of partitions:
16MB for swap (minimum), rest for
/ (a.k.a. the root
Reasons for extra partitions as discussed above include security,
quotas, and backups.
Older motherboards' BIOS has 1024 cylinder limit to locate bootable partitions,
so make small (~24-150 MiB) bootable partition near front of disk:
/home, for separate partitions.
(Show on YborStudent:
One of the most critical decisions when installing Unix or Linux is
how to best make use of limited disk space.
Even with today's large hard disks, servers with hundreds of gigabytes
of pictures, video, sound, database, and other data are common.
Multi-user machines may require protection such as read-only partitions,
disk quotas, etc.
Sizing partitions is not easy, and there are few standard answers.
(Fortunately, LVM and other modern technology makes growing
or shrinking storage volumes much simpler than previously.
So it isn't as big a deal to make a mistake in the size.)
Some reasonable default, general recommendations include:
Make swap at least as large as the physical RAM.
/tmp could be ≥1.5 the amount of virtual memory, unless you
know you need more (say for video production) or less (say for a
(Often, a RAM disk is used for
/tmp instead, which will grow
A partitioning scheme (commonly called a partition map, partition plan, or disk layout) for your system must be well documented or it is useless. Later on you will need to refer to this information and it may be difficult to recall details six or twelve months from now.
Your partition map should be neatly typed and include a description of your disk partitioning map and the scenario it is based on. (That is the scenario might be “this is a partitioning map for an at-home workstation”, “... for a web server”, “... for a multi-user development platform”, etc.)
You must justify the choices you make.
(For example, for a student server: “We have 5 classes of less than
30 students each, and low graphic web pages, Perl scripts, and
general Unix shell scripting means each student is likely to need
less than 5 MiB, so
30 * 5 * 5MiB = 750MiB
minimum, and to allow room for additional classes in the future
1GiB will be used.”)
You should summarize your partition map in a short table, something like these examples:
|Part #||Mount Point||Size||Notes|
|2||swap||256 MB||(assuming 128 MB of RAM)|
|52|| ||100 MB||...|
|Part # /
|2||swap||4 GB||(assuming 2 GB of RAM)|
|5||—||150 GB||formatted as an LVM physical volume;|
holds volume group VG1
||20 GB||Logical volume in VG1|
||10 GB||Logical volume in VG1|
||100 GB||Logical volume in VG1|
|20 GB||Logical volume in VG1|
|6||—||rest of disk||formatted as an LVM physical volume;|
holds volume group VG2
||rest of disk||Logical volume in VG2|
|Slice #||Mount Point||Size||Notes|
|Primary Solaris Partition|
|1||swap||2 GB|| assuming 2 GB of RAM.
Swap normally placed in cylinders on|
the inside of the disk, as it won't be used much and wasting the
best performing area of the disk. If the system is short of RAM,
having swap near the outer edge of the disk is better.
|2||reserved||—||refers to whole partition (for backups)|
||5 GB|| traditional Solaris location for NFS/Samba
shares and user|
home directories (
|6||un-named||60 GB||SVM pool for “soft” partitions|
|7||un-named||32 MB|| needed for meta-device DB replicas,
used when (re-)mirroring|
disks with SVM (OK to reserve this if SVM might ever be used)
Each replica needs 4 MB and only 2 or 3 are needed, but wasting
20 MB is okay and some folks recommend this size
|SVM “Soft” Partitions — grow as needed|
|—|| ||4 GB||...|
|30 GB|| the web site including web content, servlets
|—|| ||10 GB||...|
|—|| ||6 GB|| only needed if you plan to keep a lot of on-line log data|
(e.g., weeks to months). Best practice is to leave this as part
of root partition (and make that 6 GB larger)
|—||reserved|| rest of|
| others as needed later:
/var/mail, /var/spool, /usr/share, ...
|Part #||Mount Point||Size||Notes|
|1||swap||2 GB||(assuming 2 GB of RAM)|
||2 GB||Consider RAMfs|
To find out how large the disk is you could look at the label, check the BIOS, or check the system invoice/system description (often obtainable on the Internet using a serial number or service tag number). (In our case, you could also ask a lab tech.)
The version of Fedora Linux we are installing requires over 8 gigabytes,
not counting space you reserve for user home directories,
future additions and updates, log file space, database space, web site,
ftp site, etc.
(Of course, if you don't install everything you can get away with
a minimal system of under 1 GiB.)
To see how much space is required for various directories you could
log into a similar system (such as
and use the
Even Windows systems can benefit from a well thought out partitioning
Microsoft Best Practice recommends two or more partitions on each
These include creating a separate “swap” partition, that just
pagefile.sys file, as small as needed (e.g.,
4 GiB), and formatted with FAT32 rather
/bin/bashis not static and in the event of a system problem, if the root shell was bash the system would be unusable! This is why the root user's shell on Solaris is
/bin/sh. Never change the root user's shell on Solaris or any Unix flavor unless you know the new shell is static, or unless you know all needed DLLs are in the root partition.
There is an OS-imposed limit on the total number of partitions,
at least 15 per disk for Linux although there can be more,
perhaps up to 128 (some people report higher numbers on some systems).
The exact number depends on several factors, but is unlikely to exceed 256 (see
There is also a total number of storage volumes the kernel can handle,
and there are limits imposed by various operating system configurations
and various standard utilities.