5 ms·

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 (an

by 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.
- madez 11y ago
  Your arguments are irrelevant nowadays. If my filesystem gets corrupted, I boot into a live cd, just like everybody does. With btrfs and integrated parity, checksums, cow and scrubbing on the horizon filesystem reliability is only a minor thing to care about. With subvolumes we can snapshot as many things atomically as we want. Simlicity is now what trumps your arguments overwhelmingly. The filesystem hierarchy has to be intuitive, consistent and simple, which it is currently not.
  - thaumaturgy 11y ago
    There was a major ext4 bug just earlier this year that caused data loss for some folks: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 Booting a LiveCD would not have fixed affected partitions. You're not the first on HN to say in so many words that the sometimes expensive lessons I've learned over 30 years of computing are suddenly irrelevant now. I used to argue that, but I don't see much point to it anymore.
    - madez 11y ago
      One of your arguments was to put /bin and /sbin onto a seperate partition so that if something happens, it’s unlikely that /bin and /sbin are affected. In reality however, nobody cares about /bin and /sbin at all. Another argument was more fine grained permission control. You can do that by other means, for example with subvolumes. So, after all, possible corruptions are not alleviated by complex partition struture, or only with a bad trade-off for complexity. Instead, do backups. Easy and reliable. Everbody is happy, without many partitions. Simplicity is crucial and it's one thing the free software ecosystem is consistently getting wrong. I see it as the major showstopper for many people to use it more intensively. The filesystem hierarchy is just one culprit, but a fundamental one. Take a look at at some fundamental pure mathematics lectures or books. You can immediately see that this was designed to be as easy as possible. Software must be the same.
  - felixgallo 11y ago
    I boot my rackmount servers in a cage at the dc using a what now?

by powera 11y ago

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.

madez 11y ago
Your arguments are irrelevant nowadays. If my filesystem gets corrupted, I boot into a live cd, just like everybody does. With btrfs and integrated parity, checksums, cow and scrubbing on the horizon filesystem reliability is only a minor thing to care about. With subvolumes we can snapshot as many things atomically as we want. Simlicity is now what trumps your arguments overwhelmingly. The filesystem hierarchy has to be intuitive, consistent and simple, which it is currently not.
- thaumaturgy 11y ago
  There was a major ext4 bug just earlier this year that caused data loss for some folks: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 Booting a LiveCD would not have fixed affected partitions. You're not the first on HN to say in so many words that the sometimes expensive lessons I've learned over 30 years of computing are suddenly irrelevant now. I used to argue that, but I don't see much point to it anymore.
  - madez 11y ago
    One of your arguments was to put /bin and /sbin onto a seperate partition so that if something happens, it’s unlikely that /bin and /sbin are affected. In reality however, nobody cares about /bin and /sbin at all. Another argument was more fine grained permission control. You can do that by other means, for example with subvolumes. So, after all, possible corruptions are not alleviated by complex partition struture, or only with a bad trade-off for complexity. Instead, do backups. Easy and reliable. Everbody is happy, without many partitions. Simplicity is crucial and it's one thing the free software ecosystem is consistently getting wrong. I see it as the major showstopper for many people to use it more intensively. The filesystem hierarchy is just one culprit, but a fundamental one. Take a look at at some fundamental pure mathematics lectures or books. You can immediately see that this was designed to be as easy as possible. Software must be the same.
- felixgallo 11y ago
  I boot my rackmount servers in a cage at the dc using a what now?