MX Linux Forum

Posted: **Tue Aug 27, 2024 6:39 am**

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.

I am running MX Linux 23.3 with KDE plasma 5 and Kernel 6.1.0-23-amd64

Code: Select all

$ mount -v --types tmpfs,cgroup,pstore,efivarfs,securityfs,devtmpfs,proc,sysfs,fuse.portal,rpc_pipefs,devpts  | wc -l
17
$
$ mount -v --types tmpfs,cgroup,pstore,efivarfs,securityfs,devtmpfs,proc,sysfs,fuse.portal,rpc_pipefs,devpts 
sysfs 		on /sys					type sysfs 	(rw,nosuid,nodev,noexec,relatime)
proc 		on /proc				type proc 	(rw,nosuid,nodev,noexec,relatime)
udev 		on /dev					type devtmpfs  (rw,nosuid,relatime,size=8030812k,nr_inodes=2007703,mode=755,inode64)
devpts 		on /dev/pts 				type devpts 	(rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs 		on /run					type tmpfs 	(rw,nosuid,nodev,noexec,relatime,size=1615012k,mode=755,inode64)
tmpfs 		on /run/lock				type tmpfs 	(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
securityfs 	on /sys/kernel/security 		type securityfs (rw,relatime)
efivarfs 	on /sys/firmware/efi/efivars 		type efivarfs 	(rw,relatime)
pstore 		on /sys/fs/pstore 			type pstore 	(rw,relatime)
tmpfs 		on /dev/shm 				type tmpfs 	(rw,nosuid,nodev,noexec,relatime,size=8472900k,inode64)
rpc_pipefs 	on /run/rpc_pipefs			type rpc_pipefs (rw,relatime)
cgroup 		on /sys/fs/cgroup 			type tmpfs 	(rw,relatime,size=12k,mode=755,inode64)
systemd 	on /sys/fs/cgroup/systemd 		type cgroup 	(rw,nosuid,nodev,noexec,relatime,release_agent=/run/cgmanager/agents/cgm-release-agent.systemd,name=systemd)
tmpfs 		on /run/user/112 			type tmpfs 	(rw,nosuid,nodev,relatime,size=1615012k,mode=700,uid=112,gid=121,inode64)
tmpfs 		on /run/user/NNNN			type tmpfs 	(rw,nosuid,nodev,relatime,size=1615012k,mode=700,uid=1001,gid=1001,inode64)
tmpfs 		on /run/user/MMMM			type tmpfs 	(rw,nosuid,nodev,relatime,size=1615012k,mode=700,uid=1000,gid=1000,inode64)
portal 		on /run/user/MMMM/doc			type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Posted: **Tue Aug 27, 2024 6:56 am**

LinuxSpring1 wrote: Tue Aug 27, 2024 6:39 am Can these be reduced?

It depends. If you want your system to be unusable, go ahead and start disabling things.

LinuxSpring1 wrote: Tue Aug 27, 2024 6:39 am For example the portal, systemd, pstore, devpts, and a few tempfs should not even exist.

Where, exactly, have you been told these mountpoints shouldn't exist? Post exact links if possible.

Posted: **Tue Aug 27, 2024 7:55 am**

What's the proper amount of mount points? Also, I take it you never used Ubuntu or a system with snaps...

Posted: **Tue Aug 27, 2024 8:02 am**

The first thing that came to my mind when I read the title was "Why do we have so many fingers on our hands, two will do".

Posted: **Tue Aug 27, 2024 10:48 am**

Do you have any performance or other problems and after research you concluded that the mount points is the reason?

Posted: **Tue Aug 27, 2024 10:58 am**

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.

I think the actual answer is

no, you cannot remove them and they are correct as is.

possibly you could remove the portal one, but apps using various forms of sandboxing will likely stop working. removal of xdg-desktop-portal will probably remove it, of course along with anything that depends on xdg-desktop-portal.

Posted: **Tue Aug 27, 2024 12:25 pm**

LinuxSpring1 wrote: Tue Aug 27, 2024 6:39 am I was just going through the mount points and found that there are about 17 mount points in a typical MX Linux.

MX-23.3 fluxbox (booted systemd). They all serve their purpose.

Code: Select all

mount | wc -l
32

Posted: **Tue Aug 27, 2024 12:38 pm**

And Mozart's music had so many notes...

Posted: **Wed Aug 28, 2024 2:08 am**

Adrian wrote: Tue Aug 27, 2024 7:55 am What's the proper amount of mount points? Also, I take it you never used Ubuntu or a system with snaps...

No I have not used Ubuntu nor have I used snaps.

siamhie wrote: Tue Aug 27, 2024 12:25 pm
LinuxSpring1 wrote: Tue Aug 27, 2024 6:39 am I was just going through the mount points and found that there are about 17 mount points in a typical MX Linux.

MX-23.3 fluxbox (booted systemd). They all serve their purpose.
Code: Select all
mount | wc -l
32

What purposes are served by these mount points? IS there some documentation that I can refer to?

Posted: **Wed Aug 28, 2024 2:16 am**

I suggest starting with googling on mount points, and reading up a little on things, instead of asking us to be your google. Plenty to be found.

Posted: **Sun Sep 01, 2024 4:02 am**

LinuxSpring1 wrote: Tue Aug 27, 2024 6:39 am 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.

Posted: **Sun Sep 01, 2024 6:28 am**

Hey, @BitJam -- nice to see you!

Posted: **Sun Sep 01, 2024 11:07 pm**

BitJam wrote: Sun Sep 01, 2024 4:02 am
LinuxSpring1 wrote: Tue Aug 27, 2024 6:39 am 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.

Posted: **Mon Sep 02, 2024 3:18 am**

Jerry3904 wrote: Sun Sep 01, 2024 6:28 am Hey, @BitJam -- nice to see you!

Thanks Jerry! This was just a brief cameo appearance.

Posted: **Mon Sep 02, 2024 4:00 am**

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.

Posted: **Tue Sep 03, 2024 6:39 am**

davidy wrote: Mon Sep 02, 2024 4:00 am 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.

Posted: **Tue Sep 03, 2024 8:42 am**

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

BitJam wrote: Sun Sep 01, 2024 4:02 amOne 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.

MX Linux Forum

Why so many mounted file systems in MX

Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX [Solved]

toast2:Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: toast2:Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX

Re: Why so many mounted file systems in MX