Quote:
|
It's not about RAM usage but about available file names and mixing regular user-created files with glibc-created special purpose files. Every file you create in /dev/shm for other purposes is one less file name available for a shared memory segment, and it doesn't belong to a shared memory segment.
|
I found an interesting
online discussion. Within that discussion the author links to a history of /dev/shm. According to
that author, shared memory objects use 32-bit binary integer names, not alpha-numeric names.
That author also states /dev/shm has been a common dumping ground for temporary files for a long time. The fact that the overall topic of that discussion is about setting the noexec option for /dev/shm indicates that using /dev/shm for temporary files and not just shared memory segments is common practice.
Within that discussion is the same point raised here: that "POSIX shared memory objects are implemented on Linux using a tmpfs filesystem mounted at /dev/shm." This is a minimal expectation and not a restrictive specification. Nothing in such a statement says that other tmpfs tasks can't use /dev/shm.
Yes, that helps some. Thanks. Although I see no difference on my system when I run the ipcs command as user or root. Same results.
Interesting to see that running ipcs and ls /dev/shm produce two very different results. Granted, a shared memory segment is not a file per se and the ls command will not show such usage. I don't see anything in the ipcs results that use anything like a traditional file name. I'm back to the original point: what conflicts exist or are possible.
The Linux kernel has supported tmpfs and shared memory for many years. If using /dev/shm as a common mount point for non-persistent files has caused conflicts then I suspect I would find such articles or how-tos. I don't.
I understand the distinction. Originally /dev/shm was intended as a knowable mount point for shared memory segments. tmpfs is a file system that exists in RAM for storing volatile non-persistent data. Similar but not the same.
I have found nothing explicitly stating that /dev/shm can't be used for other purposes. Only that /dev/shm must exist for those apps expecting to support shared memory segments. Because the ls command can't see or show anything that is actually a shared memory segment, and shared memory segments use 32 bit binary integers for names, I remain stumped why there might be conflicts.
I understand that some people might want to keep the two concepts separate. The analogy of storing man pages in /usr/bin is fine but like any analogy, limited. The FHS documentation addresses where certain types of files should be stored. The FHS identifies expected places to store man pages. I find nothing in the FHS addressing /dev/shm, shared memory, or tmpfs.
A file system is a file system. Once created that system can be used to store files.
/tmp is listed in FHS to be used for non-persistent temporary files. /var/tmp is listed in FHS to be used for persistent temporary files. /dev/shm is not listed in FHS but the general intent is to provide a knowable location for apps expecting to use shared memory segments. Like /tmp and /var/tmp that does not mean other files can't be stored in those locations.
Consider that the default in most Slackware build scripts is to perform all operations in /tmp. Every file created in that build process except the final package would be considered non-persistent. Yet many build scripts do not delete those files and a common problem addressed in this forum is the excessive accumulation of such files in /tmp. Many distros are designed to clean /tmp every 10 days or so. The stock Slackware does not do that. The result is /tmp is being used for persistent storage rather than non-persistent. I suspect that many people at one time or another have dumped files into /tmp and then left those files there long-term before deciding what to do with the files. So the definition of temporary and non-persistent become fuzzy.
With that said, /dev/shm might not be a Puritan appropriate place to dump any kind of non-persistent file, but there is nothing inherently wrong with that either. Operating systems do not come to a screeching halt.
I realize the FHS docs are overdue for updating. I have seen some writing about a new tmpfs mount point called /run that is supposed to alleviate some tmpfs and non-persistent file and boot issues. Proposals include moving /dev/shm to /run. However, since /run is supposed to be tmpfs, that seems to indicate tmpfs and /dev/shm are not mutually exclusive creatures. There is further argument that placing shared memory segments in /dev/shm is non-FHS compliant because shared memory is not a device. Indeed, in most fstabs when mounting tmpfs, the device name is "none." In those discussions I have found about the new /run mount point, people have again discussed whether to use one tmpfs file system or several. So in that respect, nothing will change about using one common tmpfs location.
I understand both sides of the argument. I don't see any significant difference in real life application. What danger really exists by using /dev/shm as a common mount point for various tmpfs activities? Everything I read on the web indicates /dev/shm has multiple uses, only one of which is explicitly defined. In other words, using /dev/shm as a common tmpfs mount point might irritate purists, but arguing against such usage is pedantic. I think the question of how to use tmpfs and /dev/shm is administrative, much like the question of how to partition a hard drive.
