6 ms·

That looks fine for embedded systems or maybe some end-user systems, but doing that in a server context would be scary. The original filesystem hierarchy was de

That looks fine for embedded systems or maybe some end-user systems, but doing that in a server context would be scary. The original filesystem hierarchy was designed so that /usr, /etc, /bin, and so on would have their own partitions and in the event that something tried to eat the filesystem, you might still be able to boot into single user mode and repair the damage. I've had to do this on a handful of different servers where /usr is boned and won't mount, but I still have enough stuff available that I can fix it. Plus there are a handful of tools with smart option that take advantage of the multiple partition approach, like rm and rsync's --one-file-system option.

JdeBP 11y ago
Except, of course, that /etc/init and /bin/sh being on "their own partitions" is the opposite of what was actually the case in the original filesystem hierarchy. (Hint: Yes, /etc/init not /sbin/init .)
- thaumaturgy 11y ago
  [root@mail /]# ls -laF /etc/init ls: cannot access /etc/init: No such file or directory Sorry, I don't follow what you're saying. Or why that would make putting everything under /Programs better for that matter.
  - cesarb 11y ago
    I believe that what JdeBP is refering to is that, before /sbin existed, the binary which is now at /sbin/init used to be at /etc/init, if I recall correctly what I once read in an old FSSTND rationale.
    - thaumaturgy 11y ago
      Huh, interesting. If that's the case, it's new to me. Neat.
powera 11y ago
The original filesystem hierarchy was designed when 1MB was a large amount of space. If you want to have a separate read-only partition for system programs (and require going into single-user mode to modify that), go for it. But the rest of the /bin /etc /usr /usr/local nonsense is just because it's easier than changing to something better for most people.
- thaumaturgy 11y ago
  Someone should've posted a polite correction instead of downvoting you. So: The thinking behind the file system layout had nothing to do with the available disk space or having a read-only file system. It was, originally, entirely a hedge against corruption; before journaling file systems and all that jazz, if your system was hit by a power outage and it was in the middle of some operation or another it might corrupt whatever file system it was working in. So, you would create multiple partitions and have different directories as the mount point for each partition. Say for instance that, as a cautious sysadmin, you put /sbin on its own partition. Excellent! Since /sbin rarely gets touched, if everything goes pear-shaped, the system will still boot into single user mode and you can use tools like fsck and mount, which are under the uncorrupted /sbin partition and are statically linked. If you couldn't for some reason recover the file system on a particular partition, then you might be looking at having to load, say, /etc from backups, instead of everything under /. Over time, other software started to take advantage of multiple partition layouts to protect you from getting hurt. You could mark some partitions noexec, nosuid, or restrict operations like rm or rsync to specific partitions without having to worry about whether or not they'll crawl out of that partition and eat the world. But that's pretty old-school now. As file systems improved and corruption was less of a problem and everybody sort of gave up caring about what options rm accepted, more and more systems just mounted everything under / so that you would be maximally boned if ever there was a filesystem problem. Progress! OpenBSD is one of few operating systems left that has a set of recommendations for how to partition your system: http://www.openbsd.org/faq/faq4.html#Partitioning http://www.openbsd.org/faq/faq4.html#Partitioning So that's why I'm not a fan of "novel file system layouts"; the previous layout was designed and existed for some good reasons and I have a hunch that the people that are happy about novel file system layouts don't know about those reasons.
885895 11y ago
I nuked /usr on one of my servers for cleaning purposes some 5-6 years ago when I was still quite fresh to Unix. After reboot, I was unable to log in even as root. That was the day I learned not to change the shell of root to anything outside of /bin (I had set it to /usr/bin/bash). I was able to recover the machine with a LiveCD but still, it was annoying.

JdeBP 11y ago

Except, of course, that /etc/init and /bin/sh being on "their own partitions" is the opposite of what was actually the case in the original filesystem hierarchy. (Hint: Yes, /etc/init not /sbin/init .)

thaumaturgy 11y ago
[root@mail /]# ls -laF /etc/init ls: cannot access /etc/init: No such file or directory Sorry, I don't follow what you're saying. Or why that would make putting everything under /Programs better for that matter.
- cesarb 11y ago
  I believe that what JdeBP is refering to is that, before /sbin existed, the binary which is now at /sbin/init used to be at /etc/init, if I recall correctly what I once read in an old FSSTND rationale.
  - thaumaturgy 11y ago
    Huh, interesting. If that's the case, it's new to me. Neat.

powera 11y ago

The original filesystem hierarchy was designed when 1MB was a large amount of space. If you want to have a separate read-only partition for system programs (and require going into single-user mode to modify that), go for it. But the rest of the /bin /etc /usr /usr/local nonsense is just because it's easier than changing to something better for most people.

thaumaturgy 11y ago
Someone should've posted a polite correction instead of downvoting you. So: The thinking behind the file system layout had nothing to do with the available disk space or having a read-only file system. It was, originally, entirely a hedge against corruption; before journaling file systems and all that jazz, if your system was hit by a power outage and it was in the middle of some operation or another it might corrupt whatever file system it was working in. So, you would create multiple partitions and have different directories as the mount point for each partition. Say for instance that, as a cautious sysadmin, you put /sbin on its own partition. Excellent! Since /sbin rarely gets touched, if everything goes pear-shaped, the system will still boot into single user mode and you can use tools like fsck and mount, which are under the uncorrupted /sbin partition and are statically linked. If you couldn't for some reason recover the file system on a particular partition, then you might be looking at having to load, say, /etc from backups, instead of everything under /. Over time, other software started to take advantage of multiple partition layouts to protect you from getting hurt. You could mark some partitions noexec, nosuid, or restrict operations like rm or rsync to specific partitions without having to worry about whether or not they'll crawl out of that partition and eat the world. But that's pretty old-school now. As file systems improved and corruption was less of a problem and everybody sort of gave up caring about what options rm accepted, more and more systems just mounted everything under / so that you would be maximally boned if ever there was a filesystem problem. Progress! OpenBSD is one of few operating systems left that has a set of recommendations for how to partition your system: http://www.openbsd.org/faq/faq4.html#Partitioning http://www.openbsd.org/faq/faq4.html#Partitioning So that's why I'm not a fan of "novel file system layouts"; the previous layout was designed and existed for some good reasons and I have a hunch that the people that are happy about novel file system layouts don't know about those reasons.

885895 11y ago

I nuked /usr on one of my servers for cleaning purposes some 5-6 years ago when I was still quite fresh to Unix. After reboot, I was unable to log in even as root. That was the day I learned not to change the shell of root to anything outside of /bin (I had set it to /usr/bin/bash). I was able to recover the machine with a LiveCD but still, it was annoying.