On Wed, Jan 30, 2019 at 04:42:23PM -0500, Alex Winbow wrote: > I've heard word that /usr destined to be going away, but frankly I'm > very > surprised that multiple local filesystems is a rarity these days. The debian > installer even creates these semi-automatically. It is seriously the case > that "everyone" has /var and /tmp on the root filesystem?
Can't speak to all distros, but at least for RedHat/CentOS and derivatives, the default partitioning scheme is to put all persistent files on a single partition, possibly spanning multiple spindles (a logical volume). Files of a temporary nature get put on filesystems of a correspondingly temporary nature, which is to say "/run", "/dev", "/tmp", and anything I may have left out that does not need to survive a reboot gets put on separate filesystems (other than "/"). Distributions that have made their peace with "systemd" *have* to have "/usr" present at boot or shortly thereafter. CentOS 7.X has no separate "/usr": it's all symlinked to corresponding directories under "/". Example: "/usr/lib" --> "/lib". That's why there's no supported upgrade path from CentOS 6.X to CentOS 7.X (except for *very* carefully defined server configurations), just in case you were wondering. The "old school" way of partitioning disks tried to separate things into partitions based somewhat on where the contents came from and how likely they were to change. Three basic categories of software: (1) came with the OS; (2) other supported -- typically commercial -- software; and (3) home-grown (user written) software. There was always debate about "/usr" vs. "/opt" for the second category, and the UN*X OS vendor typically decided for you :-). Prior to the advent of true temporary filesystems (only became possible as memory became cheap and plentiful), you wanted to give filesystems with high activity their own separate partitions. This would obviously include things like "/tmp", and "/var" was usually a good candidate for a separate partition because that's where print spoolers, mail directories, USENET feeds, and so forth typically live(d). USENET was a particularly "nasty" case where the default filesystem creation parameters were typically not what you wanted -- news feeds required lots of inodes to support many small files rather than few large files. These days, the average Linux hobbyist doesn't know or care about the history or reasons why separate filesystems might be a good idea. Disk drives are large, cheap, and fast enough that one generally doesn't have to worry about where the swap partition is created relative to the rest of the disk -- the performance impact just isn't that great, particularly if the system has a metric arse-load of RAM to begin with and hardly ever touches swap. Consider yourself one of the "lucky" hobbyists if you've got an Alpha PWS to play with, becuase you *don't* have enough RAM or disk space that you can afford to be so cavalier in your attitude about disk partitioning :-). I try to do things like put "swap" and "/tmp" near the center of the spindle to minimize seek times/distances from other partitions, and for my PWS, "/tmp" is a local persistent filesystem rather than tmpfs -- there's simply not enough memory on a PWS to waste it. No choice in the matter as far as "/dev", thanks to "systemd" and "udev", but the amount of memory consumed there is minimal relative to the init system itself. Well, I hope this has at least been somewhat entertaining if not helpful :-). I've been playing around with different flavors of UN*X since 1977. First exposure was AT&T UNIX Sixth Edition on a PDP 11/70. First Linux system was SoftLanding Systems (SLS) Linux on a 386 back in 1992. I inherited my Alpha PWS-433au from a fellow who originally bought it to do some mail server software development in a Digital UNIX environment, then decided he needed a cantilever shelf for his equipment rack more than he needed the computer: I *think* I got the better end of the deal, even with having to make the 90-mile round trip out to his house to deliver the shelf and pick up the computer :-). --Bob