On Tue, Dec 21, 2010 at 2:26 AM, Fernando Lopez-Lezcano
<nando(a)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).