LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 06-01-2011, 12:27 AM   #16
acummings
Member
 
Registered: Jul 2004
Distribution: Slackware
Posts: 615

Rep: Reputation: 49

FWIW (2 cents) :-)

I get that (for me the user) to leave it open underneath /dev/shm so that the system can create files therein, undisturbed.

/dev/shm/the_sys's_POSIX_thing_going_on

And that if I want my own files of that sort for me to mount them totally elsewhere.

Thus, since I the user don't touch /dev/shm in this way the sys has it undisturbed by me.

What if I had created the above so named file . . . and that I'd done so before the sys then came along and overwrote my file with a file of the same filename?

As far as authoritative for me the user to not (not at all) use under /dev/shm but to use/mount totally elsewhere instead (I've not a clue as to the authoritativeness).
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 06-01-2011, 06:57 AM   #17
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,007

Rep: Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742Reputation: 742
Quote:
Originally Posted by lopid View Post
I've never seen anything using /dev/shm. Is there any real point of it? Isn't linux optimal enough in keeping recent files in memory, that it negates the necessity of /dev/shm?
Actually, things do use /dev/shm; if you're using Firefox, MySQL, PostgreSQL, Oracle (pretty much any RDBMS), it's used for POSIX inter-process communication (IPC).

Open a terminal window (as "you") and
Code:
ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 52133889   trona      600        393216     2          dest         
0x00000000 52166658   trona      600        393216     2          dest         
0x0056a4d5 57311235   trona      660        488        0                       
0x0056a4d6 57344004   trona      660        65536      0                       
0x00000000 59080709   trona      600        393216     2          dest         
0x00000000 59277322   trona      600        393216     2          dest         

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x0056a4d5 1671170    trona      660        1         
0xcbc384f8 491529     trona      600        1         

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages
That's with KDE, Firefox and MySQL running but MySQL is just mumbling to itself so there aren't any messages. You won't see a whole lot of use on a quiescent system but crank up a couple of users whacking away at a data base and it'll start showing up -- but you really won't see a lot of activity because semaphores message queues aren't usually large and they happen really fast.

The basic idea is like a railroad where two trains are trying to access the same track at the same time -- one gets a "go ahead" semaphore, the other gets a "wait" semaphore until the first has cleared.

If you execute ipcs as root, you'll see a little more information:
Code:
ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 65536      root       600        33554432   11         dest         
0x00000000 52133889   trona      600        393216     2          dest         
0x00000000 52166658   trona      600        393216     2          dest         
0x0056a4d5 57311235   trona      660        488        0                       
0x0056a4d6 57344004   trona      660        65536      0                       
0x00000000 59080709   trona      600        393216     2          dest         
0x00000000 59277322   trona      600        393216     2          dest         

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x00000000 294912     apache     600        1         
0x00000000 327681     apache     600        1         
0x0056a4d5 1671170    trona      660        1         
0xcbc384f8 491529     trona      600        1         

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages
Hope this helps some.
 
Old 06-01-2011, 01:22 PM   #18
rg3
Member
 
Registered: Jul 2007
Distribution: Slackware Linux
Posts: 505

Rep: Reputation: Disabled
SysV IPC mechanisms (shared memory, message queues and semaphores) do not use /dev/shm. That belongs to a different API.
 
Old 06-01-2011, 02:29 PM   #19
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,476

Rep: Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531Reputation: 531
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.

Quote:
Hope this helps some.
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.
 
Old 06-01-2011, 02:56 PM   #20
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 593

Rep: Reputation: 108Reputation: 108
Quote:
Originally Posted by Woodsman View Post
What danger really exists by using /dev/shm as a common mount point for various tmpfs activities?
To be honest, I don't like the idea to dump stinking trash into /dev/*

For the Gods sake, People! Just leave the /dev alone!

In fact, it's very easy to setup an TMPFS into /tmp or other more interesting places...
 
Old 06-02-2011, 01:22 AM   #21
acummings
Member
 
Registered: Jul 2004
Distribution: Slackware
Posts: 615

Rep: Reputation: 49
Quote:
shared memory segments use 32 bit binary integers for names
I don't have the capacity to create a naming convention like that. Unless I use a hex editor? To create a filename?

So, no conflict. No mixup.

/dev/shm must have similarity to a ram disk. Or, is it a ramdisk?

FWIW I've heard that a ramdisk can be created both wherever and in what size that I want.

--
Alan.
 
Old 06-02-2011, 08:41 PM   #22
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,436

Rep: Reputation: 407Reputation: 407Reputation: 407Reputation: 407Reputation: 407
Quote:
Originally Posted by acummings View Post
I don't have the capacity to create a naming convention like that. Unless I use a hex editor? To create a filename?

So, no conflict. No mixup.
A 32 bit integer can map onto many possible 4 ascii character strings.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Issues with /dev/pts & /dev/shm, when LFS boots zer0signal Linux From Scratch 2 12-21-2010 07:14 AM
/dev/shm not mounted /dev busy compgenius999 Linux - Newbie 1 03-03-2010 11:12 AM
Sizes of /dev /dev/shm /lib/init/rw jmoschetti45 Linux - Server 0 01-25-2010 11:20 AM
What is /dev/pts, /dev/shm? mrpc_cambodia Red Hat 1 10-18-2004 03:27 AM
What's the /dev/shm? antz1981cn Linux - Hardware 2 12-30-2002 01:55 PM


All times are GMT -5. The time now is 12:38 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration