[lug] shm filesystem and RH/KRUD 7.3
Tkil
tkil at scrye.com
Wed Jul 17 23:28:33 MDT 2002
>>>>> "Rob" == Rob Riggs <rob at pangalactic.org> writes:
Rob> It's not a file system (see where it says "none" under the
Rob> "Filesystem" heading).
That's a little misleading. It *is* a filesystem; there's just no
*device* (which is what normally shows up in that column, despite its
heading:
| $ df -k
| Filesystem 1k-blocks Used Available Use% Mounted on
| /dev/hda2 18943504 9930800 8050412 56% /
| /dev/hda1 46636 16705 27523 38% /boot
| none 58784 0 58784 0% /dev/shm
Compare this to the output of "mount":
| $ mount
| /dev/hda2 on / type ext3 (rw)
| none on /proc type proc (rw)
| usbdevfs on /proc/bus/usb type usbdevfs (rw)
| /dev/hda1 on /boot type ext3 (rw)
| none on /dev/pts type devpts (rw,gid=5,mode=620)
| none on /dev/shm type tmpfs (rw)
It definitely *is* of type tmpfs.
"Why" is another story.
The reasoning behind tmpfs was that things in tmp could generally be
thrown away every boot, and were often accessed frequently (e.g., used
for different stages of a C compiler, etc).
The correlation to shared memory is the key; shm areas are allocated,
looked up, opened, closed, and protected... all of which makes them
sound rather like files, doesn't it? Thus, a filesystem.
They're unified because a shared memory area has exactly the same
persistence and structure requirements as a "file" in a /tmp area,
so...
Rob> Remember, the tradition in Unix is to map almost everything to a
Rob> file (give everything a file-like interface from an OO
Rob> perspective).
Yes. Except that in this case, since the operations on multiple shm
areas and tmp files are those done on directories, it is exposed as a
hierarchy -- and operations on hierarchies in linux are executed
through the VFS mechanisms, thus it had to be a "filesystem", thus
tmpfs.
(At least that's my understanding...)
Rob> No memory is used until a process needs to allocate shared memory
Rob> segments.
Right.
t.
More information about the LUG
mailing list