Unix/Linux Disk Partitioning Guide


Written by


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 standard layout.  However modern systems now support many “per-filesystem” features, including security and robustness related mount 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 limit.  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:

Some reasons not to partition a disk include:

When Things Go Wrong

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 layout.)  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 application in /opt/nifty, only the /opt partition (which might be the root partition) doesn't have enough free space.  How annoying!  But if /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.)

Sizing Partitions

A frequently asked question is how large should the XYZ partition be?  Unfortunately there is no simple answer.  Consider a partition for /var/log.  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 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 up to 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.)

Sizing swap space is hard: if you have lots of RAM and never worry about running out, and are not using hibernation or crash reports, and are not worried about a bug in (say) a video editor program consuming all memory, then you don’t need any swap space at all.  However, even then having some is a good idea, as the system can optimize its use of memory for cache buffers (meaning it might be better to swap in some cases).

Consider sizing partitions on a mail server.  The critical partition will be the one holding the user's mail.  This may be stored in mailbox files in /var/mail 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 gmail.  (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 10 MiB 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:

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.

Planning Disk Layouts

If you plan to use Solaris “live upgrade”, you must duplicate all slices that contain files added by the installer/patch manager.  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 duplicate both / (root), /var, and so on.  Thus, best advice is to not sub-partition any standard paths in /var or /usr.  It is okay to create new directories such as /website 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

Tools for partitioning DOS/MBR disks include fdisk, cfdisk (like fdisk but with a curses UI), sfdisk (scriptable fdisk replacement that does more), gdisk (modern replacements that understand GPT disks), format, Disk Druid, parted, gparted and qtparted, 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 gparted.sourceforge.net.

Only a few of those tools have been updated to support EFI/GPT disks.  However you can use gdisk, cgdisk, and 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 disk).  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: /boot (Linux), /kernel (Solaris), or /stand (BSD).  Consider /tmp, /var, /var/log, and /home, for separate partitions.  (Show on YborStudent: df -h.)

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 DNS server).  (Often, a RAM disk is used for /tmp instead, which will grow as needed.)

Partitioning Scheme Documentation

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 /home needs 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:

Partitioning Map for 4 GiB hard disk,
For a single user workstation, no LVM

Sample partitioning summary #1
Part # Mount Point Size Notes
1 / (root) 3 GB ...
2 swap 256 MB (assuming 128 MB of RAM)
3 /home 100 MB ...
52 /tmp 100 MB ...
6 /var 100 MB ...
... ... ... ...

Partitioning Map for 500 GB hard disk, Fedora,
For a home user's multi-media development workstation using LVM

Sample partitioning summary #2
Part # /
LV name
Mount Point Size Notes
1 / (root) 30 GB ...
2 swap 4 GB (assuming 2 GB of RAM)
3 /boot 200 MB ...
5150 GB formatted as an LVM physical volume;
holds volume group VG1
homeLV /home 20 GB Logical volume in VG1
tmpLV /tmp 10 GB Logical volume in VG1
varLV /var 100 GB Logical volume in VG1
optLV /opt
(or /usr/local)
20 GB Logical volume in VG1
6rest of disk formatted as an LVM physical volume;
holds volume group VG2
moviesLV /movies rest of disk Logical volume in VG2

Partitioning Map for Solaris 10 with 80 GB hard disk plus mirror
web and application server

Sample partitioning summary #3
Slice #Mount Point Size Notes
Primary Solaris Partition
0 / (root) 12 GB ...
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)
3 unused   —   —
4 unused   —   —
5 /export 5 GB traditional Solaris location for NFS/Samba shares and user
home directories (/export/home is mounted on /home via
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
  — /var 4 GB ...
  — /var/www
(or /www)
30 GB the web site including web content, servlets and EJBs,
databases, ...
  — /opt 10 GB ...
  — /var/log 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
SVM pool
others as needed later: /crash-dump, /var/audio-video,
/var/mail, /var/spool, /usr/share, ...

Thanks to Ian Collins, Darren Dunham, and Andrew Gabriel for Solaris partitioning insights.

See also wikis.sun.com/display/BigAdmin/BootDiskLayout

and Brief Notes for Solaris 10 Disk Layout

Partitioning Map for 50 GB hard disk, FreeBSD,
For a Home user's development workstation

Sample partitioning summary #4
Part # Mount Point Size Notes
1 swap 2 GB (assuming 2 GB of RAM)
2 / (root) 4 GB ...
3 /var 10 GB ...
5 /usr 10 GB ...
6 /home 20 GB ...
7 /tmp 2 GB Consider RAMfs
8 /var/log 2 GB ...


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 YborStudent.hccfl.edu) and use the du command.

Even Windows systems can benefit from a well thought out partitioning plan.  Microsoft Best Practice recommends two or more partitions on each disk.  These include creating a separate “swap” partition, that just holds the pagefile.sys file, as small as needed (e.g., 4 GiB), and formatted with FAT32 rather than NTFS.


  1. Static programs are ones that don't use any DLLs.  Note that on Solaris /bin/bash is 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.
  2. With commonly used DOS/MBR disk technology, you can have only four primary (What Solaris folk call “FDISK”) partitions.  One of these can hold an extended partition, which in turn can hold many more logical partitions.  Note, EFI/GPT disks have virtually unlimited number of partitions.

    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 DISK_MAX_PARTS in linux/genhd.h).  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.