5 ms·

What a joke. Thie filesystem hierary wasn't complex enough for him? > /var/run otoh is only available very late at boot, since /var might reside on a separate

• kragen 16y ago
  > he forgot to mention that this is a non-standard, specialized setup. In normal case, /var is on the root partition. Specialized it may be, but nonstandard it is not; the entire reason for /var to exist as a separate directory is so that it can be mounted from a local disk in cases where your root partition and /usr are NFS-mounted or otherwise read-only or shared between multiple machines. It seems to me that moving /var/run to /run simplifies the filesystem "hierary" rather than making it more complex.
  • nwmcsween 16y ago
    To add to this hypocrisy systemd doesn't allow /usr to be on a separate partition.
    • mgedmin 16y ago
      That's false: systemd handles a separate /usr just fine. It prints a warning, because most systems don't support a separate /usr partition reliably, no matter which /sbin/init they use. Consider udev scripts that rely on binaries or libraries from /usr and are triggered on hardware cold plug events, before /usr is mounted: poof, some of your hardware magically doesn't work on boot, until you re-plug. Have fun debugging it.
    • JoshTriplett 16y ago
      Can you suggest a single use case for putting /usr on a separate partition that wouldn't work far better without? Sharing /usr across the network makes no sense, since its contents need to come from the same packages and versions as /.
      • logic 16y ago
        A homogeneous environment that doesn't have formal package management is the only use case I can envision. It was a good idea back in the SunOS days (and it's probably still workable to a limited extent for the BSDs, and perhaps folks like Gentoo) when local storage wasn't as plentiful as it is today, but I think we've safely moved on at this point.
        • koenigdavidmj 16y ago
          On modern Solaris systems, isn't /bin a symlink to /usr/bin anyway? Kind of shoots down the old reasoning that /bin has the absolute minimum to get a broken system fixed, and /usr/bin has everything else.
        • JoshTriplett 16y ago
          I understand that use case, I just don't see why it makes sense to share /usr rather than sharing /.
      • jdabney 16y ago
        One of our supercomputing clusters does run with a shared / and a separate /var that is local to the machine. /var is local to the disk because the nodes are stateless but we would like a persistence store for things like logs.
        • pyre 16y ago
          I realize that you're probably just providing a tangential anecdote, but his reasoning for why sharing /usr is useless doesn't really apply to /var.
      • kragen 16y ago
        My recollections may not be totally accurate, but I'll try. In 1997, I was working at TCSI. My SPARC 5 workstation had a small local disk, which had crucial things like vi on it, which were fast to access. It might have been 500 megabytes or less. /usr was NFS-mounted over an unswitched 10-megabit Ethernet to a gigantic 35-gigabyte NFS server, from which I had access to a huge variety of software, including something like 8 versions of the CenterLine C++ compiler, much more than would fit on my local machine, but which was much slower to access. My home directory was also NFS-mounted. Installing the huge variety of software on everybody's workstation would have meant that we had to have dozens of copies of it, using up precious disk space, and furthermore that installing or updating software would need to be done on every single workstation, instead of just on the NFS server. rdist existed but wasn't widely used; rsync had just been invented. Also, "packages and versions"? pkg_add isn't what you think of as a package management system. The FHS was adapted from Unix workstation practice established before Debian invented package management as we know it today, and at a time that Slackware still didn't have package management. You could install your packages wherever you wanted, much as people do today with easy_install or gems.
  • ianburrell 16y ago
    It sounds like one of the motivations for this change is to allow the root partition to be kept read-only. For that to work, /var would need to be a separate partition and writable. There are still a few files and directories, like /etc/lvm/cache, which currently need to be writable and could be moved to /run.
    • pyre 16y ago
      There is an exchange between Lennart and a commenter in the comments to that effect. /etc/mtab is mentioned and Lennart says that in F15 it will be a symlink to /proc/self/mounts. http://lwn.net/Articles/436022/ http://lwn.net/Articles/436022/
• pyre 16y ago
  If this was such a niche issue, then getting all of the major distros to agree on a course of action would have been much harder.
• protomyth 16y ago
  > he forgot to mention that this is a non-standard, specialized setup. In normal case, /var is on the root partition. I guess I have been hanging out in BSD land and haven't setup a Linux system. Is this correct? I generally have /var separate from / (along with /usr, /tmp, /home). How does the average HNer setup their Linux partitions?
• logic 16y ago
  Your experience does not mirror my own, I'm afraid. The failure mode of not separating out /var from the rest of the system is interesting; spool, cache, lib, and log can be particularly problematic, depending on the purpose of your system. Not separating filesystems for hobby systems and home computing is perfectly reasonable in the name of simplicity, but there's a reason longbeards like me prefer to do things this way. (Sadly, I was cursed with fair, slow-growing hair, so I have never quite reached my bearded potential. My poor attitude about your new-fangled gadgets will have to suffice.)
• dexen 16y ago
  To wrap all your responses up: in non-trivial production systems, having separate /var is a good, practical idea without serious downsides -- and my original critique was unfounded for anything but simplest use cases. Thanks for all your responses :-)