Hacker News Reader

Comment by thaumaturgy | Hacker News Reader

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.

View on HN

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 .)

    [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.

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.

Huh, interesting. If that's the case, it's new to me. Neat.

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.

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

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.

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.

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

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.

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.

I boot my rackmount servers in a cage at the dc using a what now?

Your use case is a tiny minority which doesn’t provide enough justification to increase the complexity of the default, for complexity being _very_ expensive.

And this is why Linux user space is going down the tube.

Basically that exact capability is why people adopted Linux in the first place to run the servers that run the net.

I don't see how having a / that can get up and running even when the larger system housed in /usr and such is down for the count, is anything more complex that the piles of VMs and containers that is being advocated today.

You are free to set up your system as you wish. I also don’t advocate for removing options. I’m asking for a simple default. Simplicity is very important. If you can’t explain what you are doing to your parents, it is not yet simple enough.

Don’t misunderstand simplicity for triviality for they are not the same. We need to make non-trivial problems simple.

I run a multiuser shell system for hosting tmux/ssh/irc type usage. It's limiting but it's a labor of love for friends. For anything that matters I use a modern (piles of VMs and containers!) design.

Global desktop PC shipments in 2015: ~136mm (http://www.statista.com/topics/1070/pcs/)

Linux desktop penetration: ~1.33% (http://www.netmarketshare.com/operating-system-market-share....)

1.3% * 136mm = 1.77mm

Let's ignore Amazon, Google, Microsoft, Facebook, and so on, each of whom are by themselves rumored or reported to have over a million computers in their DCs. Let's further ignore the long tail of the second tier of providers, who are thousands in number and have merely hundreds of thousands of computers each in their DCs. Let's go on to ignore all of the self serve corporations in the hundreds of thousands of data centers across the world, running Linux or a derivative on thousands to hundreds of computers each.

Let's also ignore all the routers, switches, file servers, and miscellaneous other networking equipment running Linux or a derivative.

Let's further ignore all of the televisions, media players, microwaves, appliances, and other consumer goods running Linux or a derivative.

Let's look only at Android phones, which run an embedded derivative of Linux. The phone market shipped 341.5 million year over year in 2015 Q2 (http://www.idc.com/prodserv/smartphone-os-market-share.jsp). Android had an 82.8% marketshare, so that's 282.77mm.

The number of linux computers that have the ability to boot "a live cd" is 6 thousandths (.6%) of one segment of one part of the linux embedded and server market.

Linux on the desktop has not only been dead for the last 18 years, it's barely a rounding error on a single segment of a single part of the embedded and server market.

By the way, "the complexity of the default" has been fine for over 30 years, and it's still fine. Just because you don't understand it, doesn't mean it's not the right answer.

> If my filesystem gets corrupted, I boot into a live cd, just like everybody does.

And that is what makes someone take the road trip to the server farm at 2am because a ge-wiz dev thought the exact same and never considered a "rescue" mode with network capability.

https://news.ycombinator.com/item?id=3519952 discusses the article I remember reading. The comments there (which I haven't read) seem to also disagree with the article.

Thanks for the link! That article and the comments support your argument better than mine and I have to defer to ChuckMcM's expertise -- it predates mine by a lot, my first experience with Unix-like operating systems was in 1996 and his memory is better than mine anyway.

I'm 100% certain I remember the instructions for partitioning being related to file system corruption, but that may well have come long after the original design of the FSH.

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.

Reply on news.ycombinator.com