Linux Partitioning mini-FAQ
Karsten M. Self (karsten@linuxmafia.com)
Written: Monday, September 18, 2000
Modified: Tue Dec 28 19:24:30 PST 2010
NOTE: Some of the information in this page is dated though I've updated it for my latest desktop with 1 TiB storage and a 128 SSD laptop as of December, 2010. Server-side experience with various storage configurations including RAID, LVM, NFS, and upwards of 40 TiB storage is also reflected, if dimly ;-)
What's happening is that both disks and distros are getting bigger. While you can run GNU/Linux in as little as 1.7 MiB, a typical generous desktop install now will want about 6-24 GiB just for system files. Filesystem bloat seems to be about 100% every 3-4 years. As always, YMMV.
Getting partitioning right from the get-go is helpful, as modifying partition and filesystem sizes is still fairly painful. Even with partition/filesystem editors, data loss can happen (make backups), and not all filesystems are supported (as of 2010, resizing an ext4 filesystem wasn't). You'll likely have to back-up, delete partitions, repartition, create new filesystems, and restore data -- typically a process requiring much of a day, during which your system isn't usable. If in doubt, keep your system simpler (fewer partitions), and use a more complex configuration once you have experience and understand the costs/benefits.
Finally: it's becoming increasingly popular for both personal and enterprise systems to perform only minimal partitioning: boot, root, swap, and perhaps /tmp or /scratch on a larger box. I'm somewhat old-school and prefer more partitions for reasons of control and redundancy. The downside is managing more partitions and possibly finding yourself squeezed for space. There's no specific need to follow they guidelines here, though you might see some benefits (and costs) from doing so.
The following is my recommended partitioning for a typical workstation/server Debian GNU/Linux x86 box. You can also find useful guidelines the Filesystem Hierarchy Standard (FHS), part of the debian-policy package, and the Large Disk HOWTO.
Note that I'm using the SI binary prefix notation for storage capacity/size, except as given in program output, e.g.: KiB, MiB, GiB, TiB.
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.
Primary, Extended, & Logical partitions (x86 only)
The PC BIOS disk partitioning model is based on 1-4 primary partitions, one of which may be an extended partition, which may then contain additional logical partitions.
Linux really doesn't care where you put your system, with some exceptions.
MS WinXX prefers a single primary partition, though multiple primaries are possible as an undocumented feature. Some boot managers can remap partitions; see your boot manager's documentation if you plan to follow this course. Suit your preferences if you're multi-booting.
I recommend creating three primary partitions, a fourth as an extended partition, and the remainder as logical partitions within the fourth (extended) partition. /boot usually goes on the first partition and is marked bootable, though as with most things, you have other options. Second primary partition is / (root), then swap, then extended. YMMV.
You also have the option of using logical volume management (LVM). This is a means of abstracting out the underlying physical storage from the filesystem on top of it. Both logical volumes and the filesystems on them may be resized (with varying degrees of pain). I find this leads to complexity and doesn't always provide the benefits desired, but strongly recommend the LVM HOWTO for those interested in this approach.
As disk sizes increase, BIOS limitations on older (largely pre-2002) hardware may restrict what can be seen directly. Once booted, a Linux kernel can usually sort things out, but you may need to keep your boot configuration within the first smallish partition of your drive. I generally recommend a smallish /boot partition on the first primary partition for this reason. For specifics, please see the Large Disk HOWTO.
Swap
I generally go with 3x physical RAM, in two or three separate swap partitions. Allocating more swap than you have RAM for now means your swap and RAM will be more equitably matched as you bulk up RAM later. This is more swap than you'll probably want to be using on a typical basis (e.g.: if you're filling all your swap, something's wrong). But if you need it, it provides you a buffer when the system does go into a memory-overrun condition. Typically, things will get so slow that you'll notice something's wrong. The extra swap should buy you time to shut down the offending process(es). Other sources say to provide 2x physical RAM. Putting swap partitions on multiple drives (spindles), particular SATA, PATA, or SCSI drives, will automatically stripe swap for you, for increased performance. Many suspend-to-disk systems will use swap space for the restore image.
Note that a system which is swapping heavily does not suffer from too much swap, but from too little RAM (or poorly written software consuming too much RAM). Having swap means your system does run, slowly, while you address the problem. Not having swap means your programs (and possibly your entire system) crash. There was a historic penalty in overallocating swap due to the need to address the swap itself (in real memory). To the best of my knowledge this no longer applies.
For those who question the need for any swap at all, I very strongly recommend kernel hacker Martin Pool's essay Is swap space obsolete?
How many partitions
First: You only need one. Many systems are configured with just a filesystem + swap partition. Anything other than this affords control and flexibility.
Another religious issue. I start with the scheme illustrated above because:
- / needs to be mounted for the system to boot -- but other than /bin, /boot, /dev, /etc, /initrd, /lib, /root, and sbin, other directory trees don't have to be available. Increase your chances for a clean boot by reducing the inodes at risk. You are also then able to mount other partitions nosuid and/or noexec and/or read-only, for additional security. The entire partition can be duplicated elsewhere on- or off-line for additional security.
- /tmp -- highly variable. Don't risk your root partition, isolate this content. Mount noexec and/or nosuid for added protection. Some people like to mount this as an shm (shared memory) virtual disk.
- /var -- likewise, highly variable. Mount noexec and/or nosuid for added protection.
- /usr -- Largely stable. Can be mounted read-only except for package upgrades.
- /usr/local -- Largely stable, and not part of the packaging system. Can be mounted read-only, possibly nosuid.
- /home -- Variable content, usually most sensitive data both in terms of security and integrity. Can be mounted nosuid.
- A rescue partition -- A secondary boot partition sized 50-200+ MiB, containing a set of tools to use for recovering a system. In the event you hose your primary installation. Useful also for certain sorts of maintenance (filesystem conversions). Normally unmounted.
At this point, you may choose to add additional partitions if desired to match local storage, application, or hardware needs and/or limitations.
Allocation variations
I provide some guidelines to usage patterns and mounting options, as well as whether the partition is typically capable of being served over a network.
Static means that partition contents change little. Variable means they change a lot.
Mount options typically restrict features of the partition, including whether it can support executables, SUID files, and/or device files. While content on "static" partitions can change, it typically doesn't over a normal use cycle, and is modified only during system upgrades. Debian provides options to allow remounting partitions as writable and/or read-only during the upgrade process, see this debian-devel post for more information.
Note that while mount options can restrict settings, it's possible to "remount" a partition in place, and that this doesn't produce system warnings or messages. Think of this as protection against stupid mistakes and low-grade mischief, but not a significant bar to a determined cracker.
Networkable partitions can generally be shared among several systems. The distinction is that certain data, particularly those generating much I/O, or have data pertaining to local hardware and configurations, should be local to the system.
- /: A minimal installation can fit in 30 MiB or less. If you're using more than ~250 MiB, you've probably included something in your root partition you don't strictly need. Root filesystem requirements have been increasing dramatically in recent years for those using their distribution's stock kernel, as a typical set of kernel modules (2.6 kernel) exceeds 50 MiB and will undoubtedly grow further. Largely static (though it should be writable), executable, suid, local.
- /tmp: Values suggested should work for most systems. /tmp is system temporary storage. If you've got specific applications with very large temporary storage requirements (e.g.: database, analytic tools, multimedia), you're better off allocating storage to these needs specifically. PCMCIA users note that most PCMCIA utilities expect to find /tmp to allow creation of device files. I've hacked my /etc/init.d/pcmcia file to provide for this by temporarily remounting the partition. Some software (data analysis, CD/DVD authoring, video) requires large amounts of temporary storage, from 750 MiB to several GiB. Size accordingly. Variable, non-executable, non-suid, nodev, local.
- /var: if you're running extensive services (news, mail, website), you may want to increase this allotment significantly. Often various /var/spool subdirectories become their own partitions. Such partitions may consume hundreds of MiBs to multiple GiBs. Some services (mail, news) benefit by specific mount options and/or filesystem tuning, notably noatime, and large inode counts (to allow for many files). Highly variable, non-executable (?), non-suid, nodev, local.
- /usr: A minimal installation can fit in a few hundred MiB or less. Likewise, if you have to install all packages and docs, you may find 8 GiB is too thin: consider doubling the allocation. In recent years, I'm finding that documentation, libraries (particularly OpenOffice.org, *emacs, and LaTeX/tetex), and internationalizations account for the largest growth in space. Debian/Ubuntu users may want to install the localepurge package. Tune to your needs. Static, executable, suid, nodev, networkable.
- /usr/local: This is where software installed directly by you, outside of the Debian packaging system, goes. I generally symlink /opt to /usr/local/opt for storage rationalization. Tarballs, binary non-deb installations, and locally built software. Again, if you're installing lots of stuff or very large packages, you could easily use several GiB of space. Many modern distros provide pretty much any software you could want (installed under /usr), so this partition may be pretty sparsely used. Static, executable, non-suid (?), networkable.
- /home: User directories, sometimes also where services such as websites, ftp sites, and databases are parked. On workstations and shared, directly-accessed systems, usually the largest single (or aggregate) storage area. In special-purpose or embedded systems, may be little more than a vestige directory on the root filesystem. Variable, non-suid, nodev, networkable.
- /usr/src, /usr/local/src: Depending on space constraints and variability, you may want to create these as separate partitions. Variable, non-executable, non-suid, nodev, networkable.
- OtherOS: If you have a multi-boot system, you'll want to allocate space for other OSs as appropriate. Virtualization tools such as VirtualBox, qemu, Xen, or VMWare, in conjunction with networked storage protocols such as Samba or NFS, may allow you to both run and access these partitions natively from within your Linux session.
- Sub-partitioning: I've run in the past a set of (now) empbarassingly small drives -- 2/2.4 GiB each. As a result I've split out several subdirectories of /usr and parked them on other partitions. While this is possible, it's probably generally best not to subdivide your filesystems overly much -- it does increase system complexity and management. Unless this is required by space constraints, I'd suggest not doing it. But if you need the option, it's there.
- Large filesystems: With single-disk sizes in excess of
2 TiB available now (and likely far large in the future), more
generous partitioning schemes are possible. My suggestion is to
generally follow the guidelines suggested above. Even a "kitchen
sink" installation is unlikely to require more than 6-10 GiB
storage for /usr. A /usr/local partition might
call for a larger allocation, particularly if large third-party
applications are being installed. I would apply most of the
discretionary storage as suits system needs. For example:
- /home for a personal workstation.
- File storage for a fileserver.
- Mail, Usenet, or print spools for heavily taxed servers of respective function.
- Database and/or website storage for a large database or Web Server.
Filesystem Layout
The following are simply my preferences and/or recommendations.
- /opt -> /usr/local/opt I recommend creating /opt as a symlink to /usr/local/opt as this rationalizes space and conforms to typical third-party application preferences. Some applications like to go under /usr/local, others under /opt. This link supports both transparently.
- /net This is a mount point for networked drives. Any SMB, NFS, or other partitions show up here.
- /mount Now required by FHS, the starting mount point for removable media and temporary mount points. Usually contains /mount/floppy, /mnt/cdrom, etc. Keeps your / partition cleaner and makes system backups a bit more rational.
My own current filesystems and utilization
Update, Dec, 2010: /usr has been bumped to 12GB on my primary system, largely a result of growing library, internationalization (i18n), and documentation storage. And I'm runing an all-SSD system, which is really amazing....
Update, May, 2008.
Further updates pending from my new desktop...
(April, 2001): Time changes all things. After a year and a half or so of running the configuration dating from my November, 1999 completion of a Red Hat-to-Debian conversion of the box, space was getting a bit pinched. I spent a day doing some partition rationalization to provide more usable space. Though sizes haven't changed much (mostly a slightly larger /usr, a slightly smaller /usr/local, and a fewer partitions overall, this gives me a bit more breathing room.
My current desktop configuration
The primary changes are:
- Elimination of /usr/doc and /usr/src, split-out partitions I'd created on account of an overflowing /usr partition.
- Increased size of /usr from 1.2 GiB to 1.9 GiB.
- Decreased size of /usr/local from 1.5 GiB to 1.2 GiB. Elimination of some data stored there made this possible.
- Increased size of /var from ~300 MiB to ~580 MiB.
- Increased size of /tmp from 100 MiB to 250 MiB.
- /mnt/misc1 became /usr/local/data, and shrank from 1 GiB to 375 MiB. This is largely used as a /home overflow via symlinks.
Utilization
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda3 152247 33526 110859 24% / /dev/hda6 249871 2004 234967 1% /tmp /dev/sda7 585008 457456 97836 83% /var /dev/hda5 495960 87588 382772 19% /var/spool/news /dev/sdb2 1929100 1518288 312816 83% /usr /dev/sda5 1209572 574152 573976 51% /usr/local /dev/hda7 378711 213496 145662 60% /usr/local/data /dev/hda2 1007992 584132 372656 62% /home /dev/hda1 157044 119252 37792 76% /mnt/dos
Partitioning
Disk /dev/hda: 128 heads, 63 sectors, 620 cylinders Units = cylinders of 8064 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 1 39 157216+ 6 FAT16 /dev/hda2 40 293 1024128 83 Linux /dev/hda3 * 294 332 157248 83 Linux /dev/hda4 333 620 1161216 5 Extended /dev/hda5 333 459 512032+ 83 Linux /dev/hda6 460 523 258016+ 83 Linux /dev/hda7 524 620 391072+ 83 Linux Disk /dev/sda: 255 heads, 63 sectors, 261 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sda1 1 17 136521 82 Linux swap /dev/sda2 18 261 1959930 5 Extended /dev/sda5 18 170 1228941 83 Linux /dev/sda6 171 187 136521 82 Linux swap /dev/sda7 188 261 594373+ 83 Linux Disk /dev/sdb: 255 heads, 63 sectors, 261 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 17 136521 82 Linux swap /dev/sdb2 18 261 1959930 83 Linux
/etc/fstab
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> /dev/hda3 / ext2 defaults,errors=remount-ro 0 1 proc /proc proc defaults 0 0 /dev/hda6 /tmp ext2 defaults,nosuid,nodev 0 2 /dev/sda7 /var ext2 defaults,nosuid,nodev 0 2 /dev/hda5 /var/spool/news ext2 defaults,nosuid,noexec,nodev 0 2 /dev/sdb2 /usr ext2 defaults,rw,nodev 0 2 /dev/sda5 /usr/local ext2 defaults,rw,nosuid,nodev 0 2 /dev/hda7 /usr/local/data ext2 defaults,nosuid,nodev 2 2 /dev/hda2 /home ext2 defaults,nosuid,nodev 0 2 /dev/hdc /mnt/cdrom iso9660 noauto,user,ro,nodev,nosuid 2 2 /dev/fd0 /mnt/floppy auto noauto,gid=disk,umask=007,rw,user 2 2 /dev/hda1 /mnt/dos vfat auto,user,nosuid,nodev,gid=6,umask=002 2 2 /dev/sda1 none swap sw 0 0 /dev/sdb1 none swap sw 0 0 /dev/sda6 none swap sw 0 0
A suggested laptop/desktop configuration
For a Thinkpad T42p with a 60 GiB internal drive, running Debian lenny/sid:
Filesystems are now all ext3fs, though you might keep your /boot filesystem as ext2 -- journaling buys you very little on a small filesystem usually mounted read-only, and the journal file itself eats up considerable space.
Utilization
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 242566 188356 41686 82% /
/dev/hda1 121483 32283 82927 29% /boot
/dev/hda5 961824 81420 831544 9% /tmp
/dev/hda6 11534936 9647048 1301940 89% /usr
/dev/hda7 3845088 3325876 323892 92% /var
/dev/hda8 242534 92243 137769 41% /usr/local
/dev/hda9 242534 6176 223836 3% /system2
/dev/hda10 38556920 29833736 6764592 82% /home
Partitioning
Disk /dev/hda: 60.0 GB, 60011642880 bytes
16 heads, 63 sectors/track, 116280 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/hda1 * 1 249 125464+ 83 Linux
/dev/hda2 250 746 250488 83 Linux
/dev/hda3 747 4622 1953504 82 Linux swap / Solaris
/dev/hda4 4623 116280 56275632 5 Extended
/dev/hda5 4623 6561 977224+ 83 Linux
/dev/hda6 6562 29813 11718976+ 83 Linux
/dev/hda7 29814 37564 3906472+ 83 Linux
/dev/hda8 37565 38061 250456+ 83 Linux
/dev/hda9 38062 38558 250456+ 83 Linux
/dev/hda10 38559 116280 39171856+ 83 Linux
/etc/fstab
# /etc/fstab: static file system information.
#
# file system mount point type options dump pass
/dev/hda2 / ext3 defaults 0 1
/dev/hda1 /boot ext3 ro,nosuid,nodev 0 2
/dev/hda3 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/fd0 /media/floppy auto noauto,rw,sync,user,exec 0 0
/dev/cdrom /media/cdrom iso9660 noauto,ro,user,exec 0 0
/dev/hda5 /tmp ext2 rw,nosuid,nodev 0 2
/dev/hda6 /usr ext3 rw,nodev 0 2
/dev/hda7 /var ext3 rw,nosuid,nodev 0 2
/dev/hda8 /usr/local ext3 rw,nodev 0 2
/dev/hda9 /system2 ext3 rw,nosuid,nodev 0 2
/dev/hda10 /home ext3 rw,nosuid,nodev 0 2
© 2000-2008 Karsten M. Self (karsten@linuxmafia.com)
Last updated
Tue Dec 28 19:24:30 PST 2010
1/p>
Distribution terms: To be determined, but leaning generally toward GNU GPL, the GNU Free Documentation License. Most likely not the Open Publication License. Input welcomed.