Why so many mounted file systems in MX [Solved]

[BitJam]

I was just going through the mount points and found that there are about 17 mount points in a typical MX Linux. Please see the details given below. Why does MX need to have so many mount points in a running system? Can these be reduced? For example the portal, systemd, pstore, devpts, and a few tempfs should not even exist.

One of the revolutionary ideas of the Unix operating system, on which Linux is based, was everything is a file which allows the same set of tools to be used on a wide range of resources. In some ways this has evolved into many things are filesystems. Communicating with the kernel via /sys/ and /proc/ are classic examples as is the /dev/ directory for talking to physical (and other) devices.

In addition, it is often extremely convenient to mount some directories as tmpfs which puts the file system in RAM. This is fast and prevents needless wear and tear on a physical device, but often just as important it greatly simplifies cleanup when the system or a complicated process shuts down.

There are also bind mounts which allow you to mount the same file system at multiple locations. This is another extremely powerful and useful tool. Union file systems, like aufs and overlayfs, are also useful. They allow you to combine two file systems into one. This is one of the primary tools that made Linux live cds and live usbs possible. I'm confident there are many other types.

The use of these different file systems has blossomed because they have been found to be both useful and efficient. I expect this trend to continue and for the number of mount points in a standard Linux distro to keep increasing over time. Since mounting things is so powerful, our intuition can lead us to think that it must be resource intensive. But it is actually extremely efficient.

Granted, the system is getting more and more complex as time goes by. In some ways, these many mount points allow designers a way to deal with the ever increasing complexity while providing some isolation and safe interoperability, which was one of the main goals of object oriented programming.

Ages ago (in the 1960s and 70s), the operating system for the IBM 360 was so complex that IBM decided to stop fixing bugs in it. They found that on average each time they patched it, they created more bugs than they fixed. So they stopped fixing bug and just published a list of known bugs. Modern tools, including the plethora of file systems, along with modern practices have allowed humans to create vastly more complicated operating systems. At some level, programming and system design are about managing complexity.

[Jerry3904]

Hey, @BitJam -- nice to see you!

[LinuxSpring1]

I was just going through the mount points and found that there are about 17 mount points in a typical MX Linux. Please see the details given below. Why does MX need to have so many mount points in a running system? Can these be reduced? For example the portal, systemd, pstore, devpts, and a few tempfs should not even exist.

One of the revolutionary ideas of the Unix operating system, on which Linux is based, was everything is a file which allows the same set of tools to be used on a wide range of resources. In some ways this has evolved into many things are filesystems. Communicating with the kernel via /sys/ and /proc/ are classic examples as is the /dev/ directory for talking to physical (and other) devices.

In addition, it is often extremely convenient to mount some directories as tmpfs which puts the file system in RAM. This is fast and prevents needless wear and tear on a physical device, but often just as important it greatly simplifies cleanup when the system or a complicated process shuts down.

There are also bind mounts which allow you to mount the same file system at multiple locations. This is another extremely powerful and useful tool. Union file systems, like aufs and overlayfs, are also useful. They allow you to combine two file systems into one. This is one of the primary tools that made Linux live cds and live usbs possible. I'm confident there are many other types.

The use of these different file systems has blossomed because they have been found to be both useful and efficient. I expect this trend to continue and for the number of mount points in a standard Linux distro to keep increasing over time. Since mounting things is so powerful, our intuition can lead us to think that it must be resource intensive. But it is actually extremely efficient.

Granted, the system is getting more and more complex as time goes by. In some ways, these many mount points allow designers a way to deal with the ever increasing complexity while providing some isolation and safe interoperability, which was one of the main goals of object oriented programming.

Ages ago (in the 1960s and 70s), the operating system for the IBM 360 was so complex that IBM decided to stop fixing bugs in it. They found that on average each time they patched it, they created more bugs than they fixed. So they stopped fixing bug and just published a list of known bugs. Modern tools, including the plethora of file systems, along with modern practices have allowed humans to create vastly more complicated operating systems. At some level, programming and system design are about managing complexity.

This is perhaps the most concise and comprehensive explanation that I have received till date. Thanks.

[BitJam]

Hey, @BitJam -- nice to see you!

Thanks Jerry! This was just a brief cameo appearance.

[davidy]

Try running snapshot and when it's squashing the filesystem it creates like 50 mount points. Probably less, I haven't counted but if you open double commander when it's running that's about what it shows.

[BitJam]

Try running snapshot and when it's squashing the filesystem it creates like 50 mount points. Probably less, I haven't counted but if you open double commander when it's running that's about what it shows.

Snapshot calls our installed-to-live script which uses a bunch of bind mounts to make a "copy" of the running system with all the changes needed to make it look like a live system. We then compress this bind mount copy to create a new squashfs file for the iso.

The bind mounts make the snapshot process much more efficient. The old way was to copy the entire file system, then make changes to the copy to make it look like a live system. This big copy process was expensive time-wise and space-wise. Depending on the type of compression used (and other factors) the bind mount magic cuts 40% off the time to run snapshot and uses only 25% of the extra storage space compared with doing it to the old way.

We added a lot of extra complexity to gain both time and space efficiency. IIRC we wiped out the systems of two brave devs who were testing an early version.

You can run the installed-to-live program directly to count the mount points without having to go through the whole snapshot process. Compared to the copying and compressing that gets done, the overhead for creating all of those mount points is pretty much zero. I think other projects and even an entire distro are using similar bind mount tricks now. Our chroot-rescue program uses bind mounts and tmpfs mounts to allow you to run a shell in another Linux system (on the same computer). You can even use it to run a shell in a mounted linuxfs file from one of our iso files.

Too many notes

Roughly speaking installed-to-live makes a copy of the entire file system using a bind mount under /bind-root/. This by itself doesn't do much because any changes to the copy will show up in the original. The cool thing is we can make changes to the copy without changing the original by doing more bind mounts under the first bind mount. These changes show up in the copy but not the original.

For example, to make a general purpose iso, we need to edit the /etc/passwd (and related) files by removing all user accounts and then adding root and demo accounts with preset passwords. So we create a copy of the /etc/passwd file and bind mount the copy at /bind-root/etc/passwd. We munge this copy and the changes show up when we compress everything under /bind-root/ while the original passwd file (which the running system uses) remains untouched.

Sometimes we do have to make modification to the running system but only by touching (creating) empty files that don't already exist or by creating empty directories. We keep lists of these so we can go back and remove them when we are done.

[AK-47]

Nice to see you back @BitJam - long time no see.

One of the revolutionary ideas of the Unix operating system, on which Linux is based, was everything is a file which allows the same set of tools to be used on a wide range of resources. In some ways this has evolved into many things are filesystems. Communicating with the kernel via /sys/ and /proc/ are classic examples as is the /dev/ directory for talking to physical (and other) devices.

I used to think so also, but with the advent of more modern operating systems such as Windows NT, it is now one of the more terrible ideas of the Unix operating system. A printer isn't a file, neither is a USB mouse, and neither is shared memory, or sockets, etc. Shoehorning those as files has caused more problems (in terms of APIs and development) than it has helped, and even modern-day Linux and POSIX seems to have given up on the "everything is a file" idea and just has a bunch of ioctl() calls for interacting with devices that need more than just-a-file style interaction.
Someone by the name Benno Rice did a great talk about this: https://www.youtube.com/watch?v=9-IWMbJXoLM

Of course all those mount points the OP mentions are different pseudo-file-systems, so the OS can expose the APIs in that whole bizarro "everything is a file" method. Windows NT has more sanity by doing this using an object tree instead, but it ruins this sanity with something known as the registry.