问题
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?
回答1:
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.
回答2:
Some of the configuration tools of the Linux NET-2 and NET-3 release rely on the /proc filesystem for communicating with the kernel. This interface permits access to kernel runtime information through a filesystem-like mechanism. When mounted, you can list its files like any other filesystem, or display their contents. Typical items include the loadavg file, which contains the system load average, and meminfo, which shows current core memory and swap usage.
To this, the networking code adds the net directory. It contains a number of files that show things like the kernel ARP tables, the state of TCP connections, and the routing tables. Most network administration tools get their information from these files.
The proc filesystem (or procfs, as it is also known) is usually mounted on /proc at system boot time. The best method is to add the following line to /etc/fstab :
procfs mount point:
none /proc proc defaults
Then execute mount /proc from your /etc/rc script.
The procfs is now configured into most kernels by default. If the procfs is not in your kernel, you will get a message such as: mount: fs type procfs not supported by kernel. You will then have to recompile the kernel and answer “yes” when asked for procfs support.
Reference from : http://www.tldp.org/LDP/nag2/x-087-2-iface.procfs.html
来源：https://stackoverflow.com/questions/29840242/how-is-procfs-created