I've read many times that it's important to partition disks into smaller partitions, and that this is especially true for root or OS disks, but I've never been able to find a good reason for it. A commonly given excuse is that it improves data security: if your disk is divided into OS/data partitions (eg /, /usr, /usr/local, /home, etc, or on Windows C: (OS), D: (data)) and one fails, only that information is lost, and you can reinstall the OS or restore the data from backup without damaging the other information. Most of us (well, a lot of us) (well, some of us) use SSDs for the OS and a HDD for our data, and we all (probably) only partition each into a single partition anyway, so that argument seems specious, or at best primitive. Even if we don't use SSDs, HDDs are so cheap that using two separate drives is quite reasonable, so for the most part our disks only have a single partition on them anyway.

Which brings me to the point of the post: why partition disks at all, even into a single disk-spanning partition? I've done some experiments lately and find that, while Windows can't do anything with an unpartitioned disk, Linux and some other Unices (OpenBSD not included) have no problem with it at all:

# mkfs.ext4 /dev/sdb
mke2fs 1.42.5 (29-Jul-2012)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
262144 inodes, 1048576 blocks
52428 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1073741824
32 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
# mount /dev/sdb /mnt
# ls -l /mnt
drwx------  2 root root 16384 Dec 10 06:30 lost+found/
# mkdir /mnt/test
# ls -l /mnt
drwx------  2 root root 16384 Dec 10 16:30 lost+found
drwx------  2 root root  4096 Dec 10 16:31 test
# umount /mnt

So why bother?


Security (at the cost of perhaps more administrative annoyance if you size things wrong). From my OpenBSD desktop:

/dev/sd0b none swap sw
/dev/sd0a / ffs rw,softdep 1 1
/dev/sd0k /home ffs rw,nodev,nosuid,softdep 1 2
/dev/sd0d /tmp ffs rw,nodev,nosuid,noexec 1 2
/dev/sd0f /usr ffs rw,nodev 1 2
/dev/sd0g /usr/X11R6 ffs rw,nodev 1 2
/dev/sd0h /usr/local ffs rw,nodev 1 2
/dev/sd0j /usr/obj ffs rw,nodev,nosuid,noatime,async 1 2
/dev/sd0i /usr/src ffs rw,nodev,nosuid,noatime,async 1 2
/dev/sd0e /var ffs rw,nodev,nosuid 1 2

Benefits: something filling up /var or /home will not cause problems for other partitions. Scratch partitions can have noatime and async set on them, for higher performance. Not-device partitions disallow devices, which may help prevent the creation of a kmem or some other such device for undoubtedly nefarious purposes. Also, nosuid on various random filesystems, to eliminate those being created, however accidentally.

With only one massive partition, something can fill the entire disk (oh, did you need to write to /tmp to create that kerberos ticket to login? I'm sorry...), perhaps create random devices and suid binaries, and there's no performance tuning possible on that one big partition for different needs.

Which style makes sense will depend on the OS, site, purpose of the system, ease of management, etc.

  • Something filling up one partition will not cause problems for other partitions, but it will prevent you from using your computer anyway, so what's the point? – immibis Dec 10 '15 at 22:56
  • @immibis Not necessarily. Filling up /home won't prevent system services that someone may be using remotely from working. The someone in question could be you, trying to log in to repair the problem and getting rejected because /var/log is full. – Gilles Dec 10 '15 at 23:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.