/proc
is a filesystem because user processes can navigate through it with familiar system calls and library calls, like opendir()
, readdir()
, chdir()
and getcwd()
. Even open()
, read()
and close()
work on a lot of the "files" that appear in /proc
. For most intents and almost all purposes, /proc
is a filesystem, despite the fact that its files don’t occupy blocks on some disk.
I suppose we should all clarify what definition of the term “file system” we are currently using. In the context of ext4, when we write “file system”, we’re probably talking about the combination of a layout of disk blocks, specification of metadata information about the disk blocks that also resides somewhere on disk, and the code that deals with that on-disk layout. In the context of /usr
, /tmp
, /var/run
and so on, we’re writing about an understanding or a shared conceptualization of how to name some things. Those two uses of the term “file system” are indeed quite different. /proc
is really the second kind of “file system”, as you’ve noted.
/proc
unless one thinks that files are always disk-backed (or tape-backed, or CD-backed, or whatever-backed9. They are not always - think of RAM-disks. Also, even an open/write/close sequence with a "real" file in/home
, say, may not always mean that corresponding changes intended to permanently reflect the state of this file ondisk storagehave already been made and completed. – Hagen von Eitzen May 17 '15 at 20:51