On 5/15/06, David Rosenstrauch <[EMAIL PROTECTED]> wrote:
Correct. Here's a URL on the topic (a bit dated): http://www-128.ibm.com/developerworks/library/l-fs3.html
Very similar approach to Solaris' usage of /tmp space.
This varies with each distribution. With Arch there is an rc called process (I believe) which cleans out /tmp at boot. Under other distros (e.g. Redhat/Fedora) the /tmp dir is not cleaned out automatically.
Judd Vinet wrote:
> On Sat, May 13, 2006 at 11:10:52AM -0400, David Rosenstrauch wrote:
>> What restriction are you referring to? I've always had my /tmp set to
>> 1GB and have never had a prob.
>
> That works well enough if you have the RAM. IIRC, tmpfs will only use
> up to half your RAM, so unless you have 2GB or you force it, most people
> don't have a 1GB tmpfs mount.
>
> As Rohan said, we removed it awhile ago to fix issues with apps like
> k3b that need more space in /tmp. Obviously, you are free to keep it in
> place if it works for you, but the default is to not use it.
>
>
> - J
Hmmm. I thought I remembered reading somewhere that the way tmpfs
worked was that if it didn't have sufficient space in RAM, then it would
use swap space for the rest. So if I specify 1GB, I will have access to
that amount of space in /tmp, though not all of it will be in RAM at any
given time. Seems like a reasonable way to assure sufficient /tmp space
to me, and would address the k3b problems.
Correct. Here's a URL on the topic (a bit dated): http://www-128.ibm.com/developerworks/library/l-fs3.html
Very similar approach to Solaris' usage of /tmp space.
Also, if you don't have /tmp assigned to tmpfs space, won't you have old
temp files hanging around that you don't want? If you assign /tmp to
tmpfs space, then you're guaranteed that it will be wiped clean on next
reboot.
This varies with each distribution. With Arch there is an rc called process (I believe) which cleans out /tmp at boot. Under other distros (e.g. Redhat/Fedora) the /tmp dir is not cleaned out automatically.
Anyway, I was just wondering what the reason was for the change, which
you provided. Thanks for the FYI.
DR
_______________________________________________
arch mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/arch
--
****************
jps
_______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
