On Tue, Dec 21, 2010 at 2:26 AM, Fernando Lopez-Lezcano nando@ccrma.stanford.edu wrote:
On 12/20/2010 02:17 PM, Adam Jackson wrote:
On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
I would like to bring to the attention of the list another current usage of the tmpfs mounted on /dev/shm in Fedora packages:
Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). "/tmp" is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack.
This is right and wrong.
Right! Thanks very much for looking at this in such detail (I presume you looked at the 1.9.6 code base?).
JACK uses /dev/shm for two purposes on Linux [1]. The first is as the definition of what its configure script calls HOST_DEFAULT_TMP_DIR. This path is only used as a name to which to attach the jack sockets. The extent to which this will _ever_ touch the disk, even on a journaled filesystem, is:
- eventually, the inode for that socket and the dnode for the containing
directory will have to be written to the disk, once.
>
- under memory pressure the vfs may decide to throw away the inode cache
for that socket, which would then have to be re-read from disk for subsequent connecting JACK clients.
In other words, these are setup costs, not maintenance costs. This may cause glitches in a realtime scenario to the extent that clients are created and destroyed, but in general I submit that the cost of exec() of those new clients is going to dwarf the cost of the inode cache miss for the JACK socket. [2]
My experience (caveat: a long time ago, maybe everything has changed internally in both jack and the kernel and that has invalidated my experience cache :-) was that using /tmp would lead to constant - not all the time, but very frequent and not correlated with client connection/disconnection - xruns (glitches in the audio), using /dev/shm would fix that immediately. That was why things were moved over to /dev/shm if I remember correctly.
Well /tmp should be mounted tmpfs anyway (I have been doing this for years and it is working just fine). tmp isn't a persistent storage so it makes a lot of sense, and it is *not* a dumping ground for giant files (apps that try to do that are just broken).