ZFS takes this concept up one level of abstraction. You have a `zpool` which is a collection of disks. You then have "datasets" which would be analogous to partitions. One property of a dataset is a mountpoint, but they have many more. In ZFS different datasets can have different compression algorithms, different checksum algorithms, different log (journal) characteristics, different ACL types, it can also manage exporting the dataset over the network (setup NFS/CIFS for you), encrypt the dataset, etc.

That might give you a glimpse into why it's useful to split off different datasets. I might want to tune my database (/var/lib/postgres) for throughput, while my home directory is tuned for maximum compression & encrypted, while my public fileshares are unencrypted, etc.

Also it's often useful to have different partitions if you need different filesystems, not every filesystem is suited for every particular usecase. Also sometimes you're constrained by other software: for instance many older bootloaders would typically have very limited filesystem support; even today your EFI system partition needs to be FAT formatted, which should serve as an obvious reason why you'd want to segregate `/boot/efi` from the rest of your system.

Sure, but none of that applies to this laptop, where they're all UFS.

If one filesystem gets full, you still can do some work on the others. You can also more easily umount a filesystem to fsck without the need of booting a live media. You can mount filesystems with different flags, like readonly on /boot to prevent accidents.

Modern smartphones do this, on Android for example you are able to find a filesystem for system binaries generally mounted readonly, a filesystem for the base OS and system apps, another filesystem for user installed apps. If a rogue app fills the entire filesystem it's resided, the system apps can still function.

Also, if you corrupt one filesystem you don't necessary trash all of your work. Especially if you corrupt the root filesytem all you need is to reinstall the OS and all of your data is still intact without having to mess with your backups.

For the most part however people have decided that slicing up your disk into multiple partitions isn't worth the hassle anymore, and almost all distros just dump everything on a giant /.

To be fair, the partitioning UX in both the FreeBSD and Debian (possibly linux in general) is scary.

It used to be scary on debian, but there's now a non-scary one starting from the etch release (Debian 4.0). The new UI is quite clear and comfortable to use, even in the "expert" mode.

What’s to be afraid of at install time? If you make something too big/small just do it again.

/opt is where several commercial packages from Sun would install, so by being separate if you updated your OS then you wouldn't necessarily have to reinstall NeWSprint or separate products that were, honestly, a complete pain in the ass to install.

Yeah... It makes more sense for /var and even /usr/local. / and /usr are both managed by the OS installation. /opt makes a little more sense because it's often used by large, third party packages any one of which could be larger than the whole of / and /usr together.

If / or /var run out of space (even now) then lots of daemons get into quite a bit of trouble. Anything from hanging to consuming a lot of CPU in the disk allocator.

It's often not possible to ssh into a machine where / or /var has filled up.

There was also the problem of file system robustness. Whilst things were a lot better than the non-UNIX platforms of the day, things weren't quite as good as they are today. These filesystems often were not journalled. That meant that if you had a power failure you could lose the entire volume. (I've personally had at least one / partition be destroyed by fsck after a power failure. I was so, so glad I didn't lose /home. /opt and /usr/local as well!)

Depending on whether you were the user or the administrator dictates which partition you prefer to survive, but at least it adds some robustness. It's nice to have things separated based on how you will restore them. / and /usr will come from the vendor. /opt will probably be a whole load of different media from all over the place.

In some Unixen (like OpenBSD) it's done so that you can enforce different partition-wide security policies (e.g. "this partition should never have executable files").

A bit of historical legacy from NFS workstations, where it was useful to have root and swap local* (for speed), but /usr common across many workstations. Those separations kind of became habit.

*Of course it was possible to have root and swap on NFS as well (for truly diskless).

Swap on NFS sounds kind of crazy.

I would think the opposite. Presumably there's zero contention so no need to worry about concurrency control like locking. You're just paging linear blocks of memory to disk and the bookkeeping remains in local host memory, so all you're doing is sending and receiving fixed, independent blocks of memory that are opaque to the remote host. And prior to v4 NFS was UDP and stateless, so the code to do this from the kernel could be kept quite simple.

The functional equivalent to this is iSCSI, which as far as I understand is similar to if not literally what AWS uses under the covers for EC2 block devices.

> The functional equivalent to this is iSCSI, which as far as I understand is similar to if not literally what AWS uses under the covers for EC2 block devices.

Back when disk-SSD hybrid storage was still a novel idea (~2006), one of the guys at Sun had an interesting demo with ZFS.

He first created a bunch of storage pools on a server on the east coast from iSCSI volumes on the west coast, install Postgres, and did a benchmark. He next created a pool with the same iSCSI pools but added a local SSD as a ZIL/zlog device (for caching), and ran the same benchmark.

The SSD-enabled pool has quite close to local-disk performance of a SAN.

Disk was expensive back in the day.

Depending on your compute needs, it could have made more sense to do fully-remote X.

So if many people were running intensive like MATLAB or Mathematica, then root/swap-over-NFS made sense so that you could use your local workstations local CPU all to yourself(s) and not bog down the central server. If most people were doing modest things (xterm, mail, browsing), then running everything on the central server and displaying it on dumb X11 terminals wasn't a bad idea.

I've done swap on an nbd share... with the nbd from busybox no less... on a SparcStation LX with Gentoo (compiled on a T2000)

Splitting /usr off is mostly done for access control. Plus if the directories are already split up you have the option to move them around later. /opt is usually for 3rd party apps that arn't part of your OS distribution. Like apps that come with precompiled binaries and libraries you want to make available system wide for example.

Drives used to be really freaking small

So? All the more reason to keep it on one partition to better use the space more effectively?

Run a unix machine out of disk space.

Caveat - run a Unix machine you don't care about (i.e. a disposable VM) out of disk space.

It's much easier to recover a machine if the storage is segmented. Yeah, a single partition is more convenient, but multiple partitions are more resilient.

Two of the reasons in this era were prioritizing which filesystem you wanted to overflow first, and because you necessarily used network mounts for lots of stuff (home dirs, project dirs, GNU tools, expensive software), even on workstations.

Sun was hugely into NFS, which was both a blessing and a curse -- you'd spend 4-5 figures each on a fleet of workstations with only 105 MB local drives, and they'd tend to all end up hanging frequently, because of a server burp or network burp. It didn't even have to be a burp on a filesystem you were using -- it only had to be (stale) mounted.

(I'm not this old, but I had the excessively good fortune to have access to super-cool computers and Internet as a kid.)

It really depends on what you're doing. On a desktop/laptop/workstation 1 partition is fine. On servers, all the data is not necessarily on the same disk. It's common to have the OS itself running on local disks and have everything else mounted on some non-local storage like a Storage Area Network, Network Attached Storage, NFS shares, etc.

Sure, I'm talking about this laptop specifically which has one HDD, and partitions it heavily.

It is a lot easier to upgrade an OS on a Unix box with proper partitions separating things you want to persist across installs from the OS. Makes backups and backup restores easier as well. It’s also best to have swap space be a partition. Though these days probably doesn’t matter.

A modern Windows install has something like 4 partitions these days for the c drive. Ones labeled restore, c, and I have yet to care to figure out the other two. On boot though you see just c.

Sorry about the delayed response. I misunderstood what you were getting at. It's because it's running Solaris and Solaris had different partition scheme compared operating systems now. There's wasn't really a "desktop" version of Solaris so it would just slice up the disk the same way it would on a single disk server. It's a really old school OS.