procfs是如何创建的？ [英] How is procfs created?

问题描述

在查看 proc 目录之后，大小约为140.7TB

什么是/ proc映射到，文件是如何存在的在它创建？
$ b

proc文件系统是一个伪文件系统，用作内核数据结构的接口。

我得到它作为内核和用户空间之间的接口，但我不太了解伪文件系统是如何工作的，为什么它的规模如此巨大。每次启动时，内核是否重新创建/ proc目录？如何生成 / proc 目录;是否有一个我可以查看的实现？

解决方案

仔细阅读 proc（5）。

/ proc / 是一个虚拟 虚拟包含伪文件和目录的文件系统。这些不会消耗磁盘上的任何资源（内核内存不多 - 内核需要少量的内存来独立于文件的外观大小来服务 / proc / 在里面。）。它们只是内核和用户应用程序之间的一个方便的接口。 因此， / proc / 会为系统内部发生的事情提供一个 view 特别是， ps 命令从 / proc / 中大量访问 / proc / 给出了很多关于pid 1234进程的信息。

^{在20世纪80年代后期， / proc / 不存在-eg在SunOS3上; （例如，通过 / dev / mem ）来读取物理内核内存。这是不安全和不方便的（当内核改变的时候你必须重新编译 ps ）。}

/ proc / 中的文件的外观大小为0，但是依次可读。 / proc / self / maps 就是一个很好的例子。尝试使用 cat / proc / self / maps ，然后使用 ls -l / proc / $$ / fd / 命令一个终端。其他文件显然是巨大的，因为它们的大小传达一些重要的信息。 / proc / kcore 是一个重要的例子。它表示系统的物理内存，当然它不会吃掉所有的RAM！

内核不会在 / proc / ; 中准确地创建文件，它只是向应用程序提供了在那里看到文件的幻觉 。事实上，内核正在为每个I / O操作合成数据（例如像系统调用 =http://man7.org/linux/man-pages/man2/read.2.html =nofollow> read（2） etc ...）由用户应用程序完成。因此，实际上，大多数文件在 / proc / （特别是 / proc / self / maps 或 / proc / interrupts etc ...）的行为更像是管道而不是像文件（所以它们的大小，由 stat（2）是0，但你可以从中读取几行 - 几乎是几百字节）。

顺便说一句，有了 FUSE 文件系统，你甚至可以写一个服务器应用程序，它也给你的伪文件系统中的文件的幻象。

实际上，在你的 / proc / 中有140兆字节的内容并不意味着太多。这是很大的，因为一些 stat 系统调用报告一些<虚拟的大小，总共140TB。

After looking at the proc directory, the size is about 140.7TB

What is the /proc mapped to, how are the files present in it created?

The proc file system is a pseudo-file system which is used as an interface to kernel data structures.

I get that it acts as an interface between the kernel and userspace but I don't quite understand how a pseudo-file system works, and why it's so huge in size. Is the /proc directory recreated by the kernel every boot? How exactly is the /proc directory generated; is there a implementation of that I can view?

解决方案

Read carefully proc(5).

/proc/ is a pseudo "virtual" file system containing pseudo files and directories. These do not consume any resources on the disk (and not much in kernel memory - the kernel needs a tiny amount of memory to serve /proc/ independent of the apparent size of files in it.). They are just a convenient interface between the kernel and the user applications. So /proc/ gives a (virtual) view of what is happening inside your system. In particular, the ps command is accessing extensively /proc/ since /proc/1234/ gives a lot of information about the process of pid 1234.

^{In the late 1980s, /proc/ did not exist -e.g. on SunOS3; and programs like ps reporting status of the running system had to read physical kernel memory (e.g. thru /dev/mem). This was insecure and inconvenient (you had to recompile ps when the kernel changed).}

Several files in /proc/ have an apparent size of 0, but are sequentially readable. /proc/self/maps is a good example. Try the cat /proc/self/maps then the ls -l /proc/$$/fd/ commands in a terminal. Other files are apparently huge because their size convey some significant information. /proc/kcore is a significant example. It "represents the physical memory of the system" but of course it does not eat all the RAM!

The kernel does not exactly create files in /proc/; it just gives to applications the illusion of seeing files there. In fact, the kernel is synthetizing data for every I/O operation (e.g. syscalls like read(2) etc...) done by user applications. Hence, practically speaking, most files in /proc/ (in particular /proc/self/maps or /proc/interrupts etc...) are behaving more like pipes than like files (so their size, as given by stat(2), is 0 but you can read several lines - practically a few hundred bytes - from them).

BTW, with FUSE filesystems, you could even write a server application which also gives the illusions of files in your pseudo file-system.

Practically speaking, the 140 Terabytes of contents in your /proc/ does not mean much. It is that big because some stat syscalls report some fictious size, with a grand total of 140Tb.

这篇关于procfs是如何创建的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！