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?