查看proc目录后，大小约为140.7TB
/proc 映射到什么，其中的文件是如何创建的？
proc 文件系统是一个伪文件系统，用作内核数据结构的接口。
我知道它充当内核和用户空间之间的接口，但我不太了解伪文件系统是如何工作的，以及为什么它的大小如此之大。每次启动时内核都会重新创建 /proc 目录吗？ /proc目录到底是怎么生成的；有我可以查看的实现吗？
【问题讨论】：
标签： linux filesystems kernel
仔细阅读proc(5)。
/proc/ 是一个伪 "virtual" file system，包含伪 文件和目录。这些不会消耗磁盘上的任何资源（并且在内核内存中并不多 - 内核需要少量内存来服务/proc/，而与其中文件的表观大小无关。）。它们只是内核和用户应用程序之间的一个方便的接口。 所以/proc/ 提供了一个（虚拟）查看系统内部发生的情况。 特别是，ps 命令正在广泛访问/proc/ 因为/proc/1234/ 给出了很多关于pid 1234 的进程的信息。
在 1980 年代后期，/proc/ 并不存在 -e.g.在 SunOS3 上；并且像ps这样的程序报告运行系统的状态必须读取物理内核内存（例如通过/dev/mem）。这是不安全和不方便的（当内核改变时你必须重新编译ps）。
/proc/ 中的多个文件的表观大小为 0，但可以按顺序读取。 /proc/self/maps 就是一个很好的例子。在终端中尝试cat /proc/self/maps 然后ls -l /proc/$$/fd/ 命令。其他文件显然很大，因为它们的大小传达了一些重要信息。 /proc/kcore 是一个重要的例子。它“代表系统的物理内存”，但它当然不会吃掉所有的 RAM！
内核并没有完全在/proc/ 中创建文件；它只是让应用程序产生错觉在那里看到文件。事实上，内核正在为用户应用程序完成的每个 I/O 操作（例如 syscalls 像 read(2) 等）合成数据。因此，实际上，/proc/（特别是/proc/self/maps 或/proc/interrupts 等...）中的大多数文件的行为更像管道而不是类似文件（因此stat(2) 给出的它们的大小为0，但你可以从中读取几行 - 实际上是几百个字节）。
顺便说一句，使用FUSE 文件系统，您甚至可以编写一个服务器应用程序，它还可以在您的伪 文件系统中提供文件的错觉。
实际上，/proc/ 中的 140 TB 内容意义不大。之所以这么大，是因为一些stat 系统调用报告了一些虚构 大小，总计 140Tb。
【讨论】：
Linux NET-2 和 NET-3 版本的一些配置工具依赖 /proc 文件系统与内核通信。该接口允许通过类似文件系统的机制访问内核运行时信息。挂载后，您可以像任何其他文件系统一样列出其文件，或显示其内容。典型的项目包括 loadavg 文件，其中包含系统负载平均值，以及 meminfo，它显示当前核心内存和交换使用情况。
为此，网络代码添加了 net 目录。它包含许多显示内核 ARP 表、TCP 连接状态和路由表等内容的文件。大多数网络管理工具都从这些文件中获取信息。
proc 文件系统（也称为 procfs）通常在系统启动时安装在 /proc 上。最好的方法是在 /etc/fstab 中添加以下行 ：
procfs 挂载点：
none /proc proc defaults
然后从您的 /etc/rc 脚本中执行 mount /proc。
procfs 现在默认配置到大多数内核中。如果 procfs 不在您的内核中，您将收到如下消息： mount: fs type procfs not supported by kernel.然后，您必须重新编译内核并在要求 procfs 支持时回答“是”。
【讨论】：