4 ms·

The best explanation goes from Rob Landley: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/201

by hawski 10y ago

The best explanation goes from Rob Landley: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074... Some fragment: > When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!). > Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago. It was discussed here few times: https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=3519952 https://news.ycombinator.com/item?id=9554134 https://news.ycombinator.com/item?id=9554134

torrent-of-ions 10y ago
Considering this, I wonder why the /usr would be kept at all, assuming we keep /home. Why not just have /bin etc. since we can generally fit everything there these days?
- vbernat 10y ago
  /usr can be made read-only. It is more convenient to have everything in /usr than to have /bin, /sbin, /lib, etc.
  - vbezhenar 10y ago
    I would argue, that it's better to mount / as RO and remount /var, /home as RW.
    - lomnakkus 10y ago
      It's not just amount mounting as RO. It could physically be RO (or use e.g. dm-verity or similar)... which would be quite inconvenient if you wanted to add-site-specific directories under /. (Or if a distro wants to add a directory, or whatever.). Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
      - hawski 10y ago
        > It's not just amount mounting as RO. It could physically be RO (or use e.g. dm-verity or similar)... which would be quite inconvenient if you wanted to add-site-specific directories under /. (Or if a distro wants to add a directory, or whatever.). You could use two partition update scheme as ChromeOS. I am working on Linux distribution that have rootfs as a squashfs image and I want to have as painless updates as on ChromeOS. > Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.) You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time.
        lomnakkus 10y ago
        > You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time. Right, but that's with OverlayFS and such, right? (I.e. not just straight bind mounts.) Seems awfully complicated to solve what essentially should be a non-problem... (I'm aware OverlayFS has other uses, but in this instance it seems like overkill.) EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
        hawski 10y ago
        > Right, but that's with OverlayFS and such, right? (I.e. not just straight bind mounts.) Most probably yes, but there are probably distributions using ro rootfs + specific mounts. I think that in many cases embedded devices would use such a scheme instead of OverlayFS. EDIT: But you probably have to mount workdir and upperdir somewhere over this ro rootfs for OverlayFS to work. > EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss. I was hoping that you could read between the lines also :) I mentioned my WIP distribution. I have mounted: - squashfs ro on / - ext4 rw on /mnt/rw - /mnt/rw/var bind on /var - /mnt/rw/home bind on /home
- digi_owl 10y ago
  Because initramfs effectively already is /.
- GFK_of_xmaspast 10y ago
  > Why not just have /bin etc. .... Surely there's a lot of horrible software out there that Makes Assumptions.
VLM 10y ago
There was a brief revival during the era of NFS mounting /usr, back in the era when /usr/doc could be a significant fraction of a filesystem and shipping whatever-doc packages made sense because it takes a long time to download at 14.4. I actually had deployed production systems with /usr/doc and some other stuff NFS mounted. It doesn't make much sense anymore but before the turn of the century a meg of doc files might cost you a buck per machine, which might add up to a lot of money given a lot of machines and a lot of software... And usually you don't need /usr/doc but when you do need it you REALLY need it and don't mind if its a little slower to access via NFS than on a local drive. In the same old days, some brave people exported /usr/src. Oh and X window fonts too.
hinkley 10y ago
Situations not unlike this repeated during the initial growth phase of Linux as well. You had a bunch of undergrads and recent grads upgrading their system one piece at a time, or even taking castoffs from friends and family. Typically you had one good drive that wasn't quite big enough for all the junk you thought you needed. You also had people who would build a Linux box out of any old hardware they had left over. That's how I ended up with my first firewall.
digi_owl 10y ago
As an aside, Landley's focus have been for quite some time on the mobile/embedded uses of Linux. The Linux "community" have a bad habit of turning solutions for special scenarios into generic ones by hook or by crook. Never mind that this was addressed to the busybox mailing list, a project aimed at reimplmenting the unix coreutils as a single static binary.

by hawski 10y ago

torrent-of-ions 10y ago

Considering this, I wonder why the /usr would be kept at all, assuming we keep /home. Why not just have /bin etc. since we can generally fit everything there these days?

vbernat 10y ago
/usr can be made read-only. It is more convenient to have everything in /usr than to have /bin, /sbin, /lib, etc.
- vbezhenar 10y ago
  I would argue, that it's better to mount / as RO and remount /var, /home as RW.
  - lomnakkus 10y ago
    It's not just amount mounting as RO. It could physically be RO (or use e.g. dm-verity or similar)... which would be quite inconvenient if you wanted to add-site-specific directories under /. (Or if a distro wants to add a directory, or whatever.). Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
    - hawski 10y ago
      > It's not just amount mounting as RO. It could physically be RO (or use e.g. dm-verity or similar)... which would be quite inconvenient if you wanted to add-site-specific directories under /. (Or if a distro wants to add a directory, or whatever.). You could use two partition update scheme as ChromeOS. I am working on Linux distribution that have rootfs as a squashfs image and I want to have as painless updates as on ChromeOS. > Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.) You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time.
      - lomnakkus 10y ago
        > You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time. Right, but that's with OverlayFS and such, right? (I.e. not just straight bind mounts.) Seems awfully complicated to solve what essentially should be a non-problem... (I'm aware OverlayFS has other uses, but in this instance it seems like overkill.) EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
        hawski 10y ago
        > Right, but that's with OverlayFS and such, right? (I.e. not just straight bind mounts.) Most probably yes, but there are probably distributions using ro rootfs + specific mounts. I think that in many cases embedded devices would use such a scheme instead of OverlayFS. EDIT: But you probably have to mount workdir and upperdir somewhere over this ro rootfs for OverlayFS to work. > EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss. I was hoping that you could read between the lines also :) I mentioned my WIP distribution. I have mounted: - squashfs ro on / - ext4 rw on /mnt/rw - /mnt/rw/var bind on /var - /mnt/rw/home bind on /home
digi_owl 10y ago
Because initramfs effectively already is /.
GFK_of_xmaspast 10y ago
> Why not just have /bin etc. .... Surely there's a lot of horrible software out there that Makes Assumptions.

VLM 10y ago

There was a brief revival during the era of NFS mounting /usr, back in the era when /usr/doc could be a significant fraction of a filesystem and shipping whatever-doc packages made sense because it takes a long time to download at 14.4. I actually had deployed production systems with /usr/doc and some other stuff NFS mounted. It doesn't make much sense anymore but before the turn of the century a meg of doc files might cost you a buck per machine, which might add up to a lot of money given a lot of machines and a lot of software... And usually you don't need /usr/doc but when you do need it you REALLY need it and don't mind if its a little slower to access via NFS than on a local drive. In the same old days, some brave people exported /usr/src. Oh and X window fonts too.

hinkley 10y ago

Situations not unlike this repeated during the initial growth phase of Linux as well. You had a bunch of undergrads and recent grads upgrading their system one piece at a time, or even taking castoffs from friends and family. Typically you had one good drive that wasn't quite big enough for all the junk you thought you needed. You also had people who would build a Linux box out of any old hardware they had left over. That's how I ended up with my first firewall.

digi_owl 10y ago

As an aside, Landley's focus have been for quite some time on the mobile/embedded uses of Linux. The Linux "community" have a bad habit of turning solutions for special scenarios into generic ones by hook or by crook. Never mind that this was addressed to the busybox mailing list, a project aimed at reimplmenting the unix coreutils as a single static binary.