为什么在最近的发行版上挂载了这么多文件系统？

Question

自 1996 年左右以来，我一直在服务器上使用 Linux，并且我已经习惯看到这样的事情：

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3

（我在这里删除了“选项”，因为它们不相关。）

最近，我开始看到：

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3
devtmpfs on /dev type devtmpfs 
tmpfs on /run type tmpfs 
tmpfs on /run/lock type tmpfs 
sysfs on /sys type sysfs
tmpfs on /run/shm type tmpfs 
devpts on /dev/pts type devpts 

我想我可以理解其中的一些附加项目，尽管它们都可能proc有一点重叠......

最近，我抓住了一个桌面发行的现场ISO映像（Linux Mint的在这种特殊情况下，但我已经看到了Debian的，卡利，和其他人），有这个疯狂：

$ mount
sysfs on /sys type sysfs 
proc on /proc type proc 
udev on /dev type devtmpfs 
devpts on /dev/pts type devpts 
tmpfs on /run type tmpfs 
/dev/sda1 on / type ext4 
securityfs on /sys/kernel/security type securityfs 
tmpfs on /dev/shm type tmpfs 
tmpfs on /run/lock type tmpfs 
tmpfs on /sys/fs/cgroup type tmpfs 
cgroup on /sys/fs/cgroup/systemd type cgroup 
pstore on /sys/fs/pstore type pstore 
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
cgroup on /sys/fs/cgroup/pids type cgroup 
cgroup on /sys/fs/cgroup/hugetlb type cgroup 
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
cgroup on /sys/fs/cgroup/blkio type cgroup 
cgroup on /sys/fs/cgroup/freezer type cgroup 
cgroup on /sys/fs/cgroup/perf_event type cgroup 
cgroup on /sys/fs/cgroup/cpuset type cgroup 
cgroup on /sys/fs/cgroup/memory type cgroup 
cgroup on /sys/fs/cgroup/devices type cgroup 
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
mqueue on /dev/mqueue type mqueue 
debugfs on /sys/kernel/debug type debugfs 
hugetlbfs on /dev/hugepages type hugetlbfs 
fusectl on /sys/fs/fuse/connections type fusectl 
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
cgmfs on /run/cgmanager/fs type tmpfs 
tmpfs on /run/user/1000 type tmpfs 
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse 

这种“坐骑”泛滥的原因是什么？诸如此类的东西是否cgroups特别方便查看为“已安装”文件系统而不是通过编程 API 访问它们？

Answer 1

这是API种类的选择。

在旧系统上，通常使用设备和此类设备上的 IOCTL（例如创建虚拟终端）。问题是它依赖于使用号码来访问特定服务，因此改进/升级并不容易。此外，相同的请求号在其他设备上可能具有完全不同的含义，因此在重命名设备（更具描述性、虚拟系统等）时，可能会给出错误的命令（例如，混淆应该给予哪种设备）一个程序）。

所以还有其他选择。有时，会创建新的系统调用，但这主要是针对一般情况，并且创建许多新的系统调用也并不理想。/proc也成为一个通用接口，但存在一些问题，因为这种文件系统（内核侧）的接口对于所有服务都是相同的。APCI和网络广泛使用了这样的接口。当其他程序可以访问 proc 中的文件时，删除模块会出现一些问题。现在模块（从而删除它们以释放内存）不再是一个问题

很少尝试使用网络套接字，但对于单次使用来说不太方便。

因此，现在创建新的文件系统变得更容易，并为驱动程序/服务提供了更多的自由来实现它。还有一个优点，就是cat可以echo用来获取和提取数据。更容易测试和使用新功能。