Current merrits of tmpfs with Jack

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Current merrits of tmpfs with Jack

Russell Hanaghan
Hi to all and Merry Xmas, Festivus, whatever your preference!

Is there a major performance hit that anyone can speak to if they do not
utilize tmpfs on /tmp when using jack?

I'm looking to master a Livecd and to create it, it stores it's data in
/tmp. If I have tmpfs set on /tmp, the mastering of the cd falls out
becauges 1 gb of memory is insufficient....yet, I want /tmp to have a
tmpfs ultimately on the bootable cd.

Any thoughts?

thanks
R~
Reply | Threaded
Open this post in threaded view
|

Re: Current merrits of tmpfs with Jack

Lee Revell
On Thu, 2005-12-22 at 11:14 -0800, Russell Hanaghan wrote:
> Hi to all and Merry Xmas, Festivus, whatever your preference!
>
> Is there a major performance hit that anyone can speak to if they do not
> utilize tmpfs on /tmp when using jack?
>

Yes.

> I'm looking to master a Livecd and to create it, it stores it's data in
> /tmp. If I have tmpfs set on /tmp, the mastering of the cd falls out
> becauges 1 gb of memory is insufficient....yet, I want /tmp to have a
> tmpfs ultimately on the bootable cd.
>
> Any thoughts?

Configure JACK to use /dev/shm and leave /tmp on your root FS.

Lee

Reply | Threaded
Open this post in threaded view
|

Re: Current merrits of tmpfs with Jack

Russell Hanaghan
Lee Revell wrote:

>On Thu, 2005-12-22 at 11:14 -0800, Russell Hanaghan wrote:
>  
>
>>Hi to all and Merry Xmas, Festivus, whatever your preference!
>>
>>Is there a major performance hit that anyone can speak to if they do not
>>utilize tmpfs on /tmp when using jack?
>>
>>    
>>
>
>Yes.
>
>  
>
>>I'm looking to master a Livecd and to create it, it stores it's data in
>>/tmp. If I have tmpfs set on /tmp, the mastering of the cd falls out
>>becauges 1 gb of memory is insufficient....yet, I want /tmp to have a
>>tmpfs ultimately on the bootable cd.
>>
>>Any thoughts?
>>    
>>
>
>Configure JACK to use /dev/shm and leave /tmp on your root FS.
>
>Lee
>
>
>  
>
Jack then needs to be compiled as such right? That is, specifically to
use /dev/shm as a tmpfs?

thanks
R~
Reply | Threaded
Open this post in threaded view
|

Re: Current merrits of tmpfs with Jack

Lee Revell
On Thu, 2005-12-22 at 12:54 -0800, Russell Hanaghan wrote:

> Lee Revell wrote:
>
> >On Thu, 2005-12-22 at 11:14 -0800, Russell Hanaghan wrote:
> >  
> >
> >>Hi to all and Merry Xmas, Festivus, whatever your preference!
> >>
> >>Is there a major performance hit that anyone can speak to if they do not
> >>utilize tmpfs on /tmp when using jack?
> >>
> >>    
> >>
> >
> >Yes.
> >
> >  
> >
> >>I'm looking to master a Livecd and to create it, it stores it's data in
> >>/tmp. If I have tmpfs set on /tmp, the mastering of the cd falls out
> >>becauges 1 gb of memory is insufficient....yet, I want /tmp to have a
> >>tmpfs ultimately on the bootable cd.
> >>
> >>Any thoughts?
> >>    
> >>
> >
> >Configure JACK to use /dev/shm and leave /tmp on your root FS.
> >
> >Lee
> >
> >
> >  
> >
> Jack then needs to be compiled as such right? That is, specifically to
> use /dev/shm as a tmpfs?
>
> thanks
> R~
>

Yes.  Or configure your CD burning program to not use /tmp.

Lee

Reply | Threaded
Open this post in threaded view
|

Re: Current merrits of tmpfs with Jack

Lee Revell
In reply to this post by Russell Hanaghan
On Thu, 2005-12-22 at 12:54 -0800, Russell Hanaghan wrote:
> >Configure JACK to use /dev/shm and leave /tmp on your root FS.
> >
> >Lee
> >
> >
> >  
> >
> Jack then needs to be compiled as such right? That is, specifically to
> use /dev/shm as a tmpfs?

You know there's actually no good reason this has to be a compile time
setting.  It would be trivial to modify JACK to set this at runtime.

Lee



Reply | Threaded
Open this post in threaded view
|

Re: Current merrits of tmpfs with Jack

Paul Davis
On Thu, 2005-12-22 at 16:21 -0500, Lee Revell wrote:

> On Thu, 2005-12-22 at 12:54 -0800, Russell Hanaghan wrote:
> > >Configure JACK to use /dev/shm and leave /tmp on your root FS.
> > >
> > >Lee
> > >
> > >
> > >  
> > >
> > Jack then needs to be compiled as such right? That is, specifically to
> > use /dev/shm as a tmpfs?
>
> You know there's actually no good reason this has to be a compile time
> setting.  It would be trivial to modify JACK to set this at runtime.

how would a client know where to find the server sockets?

--p


Reply | Threaded
Open this post in threaded view
|

Re: Current merrits of tmpfs with Jack

Kjetil S. Matheussen
In reply to this post by Russell Hanaghan

Paul Davis:

> On Thu, 2005-12-22 at 16:21 -0500, Lee Revell wrote:
>> On Thu, 2005-12-22 at 12:54 -0800, Russell Hanaghan wrote:
>>>> Configure JACK to use /dev/shm and leave /tmp on your root FS.
>>>>
>>>> Lee
>>>>
>>>>
>>>>
>>>>
>>> Jack then needs to be compiled as such right? That is, specifically to
>>> use /dev/shm as a tmpfs?
>>
>> You know there's actually no good reason this has to be a compile time
>> setting.  It would be trivial to modify JACK to set this at runtime.
>
> how would a client know where to find the server sockets?
>

By having a file called something like /tmp/jack_server_sockets_path
containing info about where the server sockets are?



--
Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Lee Revell
On Thu, 2005-12-22 at 21:20 -0800, Kjetil S. Matheussen wrote:

> Paul Davis:
> > On Thu, 2005-12-22 at 16:21 -0500, Lee Revell wrote:
> >> On Thu, 2005-12-22 at 12:54 -0800, Russell Hanaghan wrote:
> >>>> Configure JACK to use /dev/shm and leave /tmp on your root FS.
> >>>>
> >>>> Lee
> >>>>
> >>>>
> >>>>
> >>>>
> >>> Jack then needs to be compiled as such right? That is, specifically to
> >>> use /dev/shm as a tmpfs?
> >>
> >> You know there's actually no good reason this has to be a compile time
> >> setting.  It would be trivial to modify JACK to set this at runtime.
> >
> > how would a client know where to find the server sockets?
> >
>
> By having a file called something like /tmp/jack_server_sockets_path
> containing info about where the server sockets are?
>

$HOME/.jack_server_sockets_path?

Lee

Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Kjetil S. Matheussen
In reply to this post by Russell Hanaghan

Lee Revell:

>> >>> Jack then needs to be compiled as such right? That is, specifically to
>> >>> use /dev/shm as a tmpfs?
>> >>
>> >> You know there's actually no good reason this has to be a compile time
>> >> setting.  It would be trivial to modify JACK to set this at runtime.
>> >
>> > how would a client know where to find the server sockets?
>> >
>>
>> By having a file called something like /tmp/jack_server_sockets_path
>> containing info about where the server sockets are?
>>
>
>$HOME/.jack_server_sockets_path?

Yes, either $HOME/.jack_server_sockets_path_<hostname>
or /tmp/jack_server_sockets_path_<username>


--
Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Paul Davis
On Fri, 2005-12-23 at 15:31 -0800, Kjetil S. Matheussen wrote:

> Lee Revell:
> >> >>> Jack then needs to be compiled as such right? That is, specifically to
> >> >>> use /dev/shm as a tmpfs?
> >> >>
> >> >> You know there's actually no good reason this has to be a compile time
> >> >> setting.  It would be trivial to modify JACK to set this at runtime.
> >> >
> >> > how would a client know where to find the server sockets?
> >> >
> >>
> >> By having a file called something like /tmp/jack_server_sockets_path
> >> containing info about where the server sockets are?
> >>
> >
> >$HOME/.jack_server_sockets_path?
>
> Yes, either $HOME/.jack_server_sockets_path_<hostname>
> or /tmp/jack_server_sockets_path_<username>

this looks to me like a 50% solution. it solves part of the problem
(allowing the location of the actual sockets/fifos to be determined at
runtime) by substituting another compile-time-only path instead. i see
the attraction, i am just not sure its the best solution.

--p


Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Russell Hanaghan
Paul Davis wrote:

>On Fri, 2005-12-23 at 15:31 -0800, Kjetil S. Matheussen wrote:
>  
>
>>Lee Revell:
>>    
>>
>>>>>>>Jack then needs to be compiled as such right? That is, specifically to
>>>>>>>use /dev/shm as a tmpfs?
>>>>>>>              
>>>>>>>
>>>>>>You know there's actually no good reason this has to be a compile time
>>>>>>setting.  It would be trivial to modify JACK to set this at runtime.
>>>>>>            
>>>>>>
>>>>>how would a client know where to find the server sockets?
>>>>>
>>>>>          
>>>>>
>>>>By having a file called something like /tmp/jack_server_sockets_path
>>>>containing info about where the server sockets are?
>>>>
>>>>        
>>>>
>>>$HOME/.jack_server_sockets_path?
>>>      
>>>
>>Yes, either $HOME/.jack_server_sockets_path_<hostname>
>>or /tmp/jack_server_sockets_path_<username>
>>    
>>
>
>this looks to me like a 50% solution. it solves part of the problem
>(allowing the location of the actual sockets/fifos to be determined at
>runtime) by substituting another compile-time-only path instead. i see
>the attraction, i am just not sure its the best solution.
>
>--p
>
>
>
>  
>
So the first solution is the most solid; compile jack to utilize /dev/shm?

Unless there is some trade off or sacrifice when doing so to either the
systems stability and performance, or to jackits stability /
performance, I don't see this as a major problem.

thanks
R~
Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Lee Revell
On Fri, 2005-12-23 at 19:46 -0800, Russell Hanaghan wrote:

> Paul Davis wrote:
>
> >On Fri, 2005-12-23 at 15:31 -0800, Kjetil S. Matheussen wrote:
> >  
> >
> >>Lee Revell:
> >>    
> >>
> >>>>>>>Jack then needs to be compiled as such right? That is, specifically to
> >>>>>>>use /dev/shm as a tmpfs?
> >>>>>>>              
> >>>>>>>
> >>>>>>You know there's actually no good reason this has to be a compile time
> >>>>>>setting.  It would be trivial to modify JACK to set this at runtime.
> >>>>>>            
> >>>>>>
> >>>>>how would a client know where to find the server sockets?
> >>>>>
> >>>>>          
> >>>>>
> >>>>By having a file called something like /tmp/jack_server_sockets_path
> >>>>containing info about where the server sockets are?
> >>>>
> >>>>        
> >>>>
> >>>$HOME/.jack_server_sockets_path?
> >>>      
> >>>
> >>Yes, either $HOME/.jack_server_sockets_path_<hostname>
> >>or /tmp/jack_server_sockets_path_<username>
> >>    
> >>
> >
> >this looks to me like a 50% solution. it solves part of the problem
> >(allowing the location of the actual sockets/fifos to be determined at
> >runtime) by substituting another compile-time-only path instead. i see
> >the attraction, i am just not sure its the best solution.
> >
> >--p
> >
> >
> >
> >  
> >
> So the first solution is the most solid; compile jack to utilize /dev/shm?
>
> Unless there is some trade off or sacrifice when doing so to either the
> systems stability and performance, or to jackits stability /
> performance, I don't see this as a major problem.

Obviously, make sure /dev/shm exists and is a tmpfs mount first but yes,
there's no trade off at all.

Lee

Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Ross Vandegrift
In reply to this post by Paul Davis
On Fri, Dec 23, 2005 at 07:11:46PM -0500, Paul Davis wrote:
> On Fri, 2005-12-23 at 15:31 -0800, Kjetil S. Matheussen wrote:
> > Yes, either $HOME/.jack_server_sockets_path_<hostname>
> > or /tmp/jack_server_sockets_path_<username>
>
> i see the attraction, i am just not sure its the best solution.

While I agree, something like /tmp/blahblah_$USER is a very common
solution to this issue.  A quick survey of my /tmp shows the following
things are doing it this way:

alsa
csdebug
gaim
gconfd
keychain
kde
ksocket
mapping
mc
mcop
mplayer
orbit
ssh-agent
xmms
xses

I can't even place where some of those are coming from!

--
Ross Vandegrift
[hidden email]

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
        --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Allan Wind
On 2005-12-24T00:13:09-0500, Ross Vandegrift wrote:
> While I agree, something like /tmp/blahblah_$USER is a very common
> solution to this issue.

Just be careful with permissions and the sequence of operations
otherwise you end up with a security hole.


/Allan
Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Russell Hanaghan
In reply to this post by Russell Hanaghan
Russell Hanaghan wrote:

> Paul Davis wrote:
>
>> On Fri, 2005-12-23 at 15:31 -0800, Kjetil S. Matheussen wrote:
>>  
>>
>>> Lee Revell:
>>>  
>>>
>>>>>>>> Jack then needs to be compiled as such right? That is,
>>>>>>>> specifically to
>>>>>>>> use /dev/shm as a tmpfs?
>>>>>>>>            
>>>>>>>
>>>>>>> You know there's actually no good reason this has to be a
>>>>>>> compile time
>>>>>>> setting.  It would be trivial to modify JACK to set this at
>>>>>>> runtime.
>>>>>>>          
>>>>>>
>>>>>> how would a client know where to find the server sockets?
>>>>>>
>>>>>>        
>>>>>
>>>>> By having a file called something like /tmp/jack_server_sockets_path
>>>>> containing info about where the server sockets are?
>>>>>
>>>>>      
>>>>
>>>> $HOME/.jack_server_sockets_path?
>>>>    
>>>
>>> Yes, either $HOME/.jack_server_sockets_path_<hostname>
>>> or /tmp/jack_server_sockets_path_<username>
>>>  
>>
>>
>> this looks to me like a 50% solution. it solves part of the problem
>> (allowing the location of the actual sockets/fifos to be determined at
>> runtime) by substituting another compile-time-only path instead. i see
>> the attraction, i am just not sure its the best solution.
>>
>> --p
>>
>>
>>
>>  
>>
> So the first solution is the most solid; compile jack to utilize
> /dev/shm?
>
> Unless there is some trade off or sacrifice when doing so to either
> the systems stability and performance, or to jackits stability /
> performance, I don't see this as a major problem.
>
> thanks
> R~
>
So next silly question...

Is a tmpfs typically set up on /dev/shm on Linux systems? If not, where
does the config for this reside?

Thanks
R~
Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Russell Hanaghan
Russell Hanaghan wrote:

> Russell Hanaghan wrote:
>
>> Paul Davis wrote:
>>
>>> On Fri, 2005-12-23 at 15:31 -0800, Kjetil S. Matheussen wrote:
>>>  
>>>
>>>> Lee Revell:
>>>>  
>>>>
>>>>>>>>> Jack then needs to be compiled as such right? That is,
>>>>>>>>> specifically to
>>>>>>>>> use /dev/shm as a tmpfs?
>>>>>>>>>            
>>>>>>>>
>>>>>>>>
>>>>>>>> You know there's actually no good reason this has to be a
>>>>>>>> compile time
>>>>>>>> setting.  It would be trivial to modify JACK to set this at
>>>>>>>> runtime.
>>>>>>>>          
>>>>>>>
>>>>>>>
>>>>>>> how would a client know where to find the server sockets?
>>>>>>>
>>>>>>>        
>>>>>>
>>>>>>
>>>>>> By having a file called something like /tmp/jack_server_sockets_path
>>>>>> containing info about where the server sockets are?
>>>>>>
>>>>>>      
>>>>>
>>>>>
>>>>> $HOME/.jack_server_sockets_path?
>>>>>    
>>>>
>>>>
>>>> Yes, either $HOME/.jack_server_sockets_path_<hostname>
>>>> or /tmp/jack_server_sockets_path_<username>
>>>>  
>>>
>>>
>>>
>>> this looks to me like a 50% solution. it solves part of the problem
>>> (allowing the location of the actual sockets/fifos to be determined at
>>> runtime) by substituting another compile-time-only path instead. i see
>>> the attraction, i am just not sure its the best solution.
>>>
>>> --p
>>>
>>>
>>>
>>>  
>>>
>> So the first solution is the most solid; compile jack to utilize
>> /dev/shm?
>>
>> Unless there is some trade off or sacrifice when doing so to either
>> the systems stability and performance, or to jackits stability /
>> performance, I don't see this as a major problem.
>>
>> thanks
>> R~
>
Ok...so no-one answered which tells me RTFM~ :) So I am reading the
sorceforge jack site pages....And now Im confused even more.

<snip>


      Prerequisites

    * 2.4, 2.5 or 2.6 series kernel with tmpfs turned on (CONFIG_TMPFS)
    * Shared memory file system mounted on /dev/shm. add the following
      to /etc/fstab to get it mounted at boot:

        shmfs       /dev/shm     shm    defaults        0       0
   

      (Note: you may have to make the /dev/shm directory)

<unsnip>

Is this the actual use of /dev/shm or can it serve dual purpose and be
also set up as tmpfs for fifo's?


Or...

<snip>

|# mkdir /mnt/ramfs|

[edit /etc/fstab and add the following line]

|none /mnt/ramfs tmpfs defaults 0 0|

Then use --with-default-tmpdir=/mnt/ramfs to the JACK configure line
when you build it. No clients need to be recompiled.

<unsnip>

Is this the better or just alternative option?

Thanks
R~




Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Jesse Chappell
On 1/7/06, Russell Hanaghan <[hidden email]> wrote:

>       Prerequisites
>
>     * 2.4, 2.5 or 2.6 series kernel with tmpfs turned on (CONFIG_TMPFS)
>     * Shared memory file system mounted on /dev/shm. add the following
>       to /etc/fstab to get it mounted at boot:
>
>         shmfs       /dev/shm     shm    defaults        0       0
>
>
>       (Note: you may have to make the /dev/shm directory)
>
> <unsnip>
>
> Is this the actual use of /dev/shm or can it serve dual purpose and be
> also set up as tmpfs for fifo's?

Yes this is the actual use of /dev/shm.  In many distros you will find
such a line already in the /etc/fstab.  And yes, it can serve dual
purpose.

> Or...
>
> |# mkdir /mnt/ramfs|
>
> [edit /etc/fstab and add the following line]
>
> |none /mnt/ramfs tmpfs defaults 0 0|
>
> Then use --with-default-tmpdir=/mnt/ramfs to the JACK configure line
> when you build it. No clients need to be recompiled.

This is just an older alternative, not better.

jlc

Reply | Threaded
Open this post in threaded view
|

Re: Re: Current merrits of tmpfs with Jack

Russell Hanaghan
Jesse Chappell wrote:

>On 1/7/06, Russell Hanaghan <[hidden email]> wrote:
>
>  
>
>>      Prerequisites
>>
>>    * 2.4, 2.5 or 2.6 series kernel with tmpfs turned on (CONFIG_TMPFS)
>>    * Shared memory file system mounted on /dev/shm. add the following
>>      to /etc/fstab to get it mounted at boot:
>>
>>        shmfs       /dev/shm     shm    defaults        0       0
>>
>>
>>      (Note: you may have to make the /dev/shm directory)
>>
>><unsnip>
>>
>>Is this the actual use of /dev/shm or can it serve dual purpose and be
>>also set up as tmpfs for fifo's?
>>    
>>
>
>Yes this is the actual use of /dev/shm.  In many distros you will find
>such a line already in the /etc/fstab.  And yes, it can serve dual
>purpose.
>
>  
>
>>Or...
>>
>>|# mkdir /mnt/ramfs|
>>
>>[edit /etc/fstab and add the following line]
>>
>>|none /mnt/ramfs tmpfs defaults 0 0|
>>
>>Then use --with-default-tmpdir=/mnt/ramfs to the JACK configure line
>>when you build it. No clients need to be recompiled.
>>    
>>
>
>This is just an older alternative, not better.
>
>jlc
>
>
>  
>
Thanks Jesse