Re: Moving /tmp to tmpfs makes it useless
2012/6/1 Roger Leigh wrote:
> I'm certainly not averse to switching the default back, if this is the
> best solution at the present time for the majority of our users.
If only it was the best solution...
> As was seen in both this an earlier discussions, there is not a clear-cut
> consensus here--there are from what I can tell approximately equal
> numbers in the "for" and "against" camps.
I don't see the "for" camp. I only see the "against" and "not against".
People from "against" camp list the problems. And others from "not against"
camp are saying that "it's not that bad". Nobody shown why it's a good
default yet.
Can you name arguments from the "for" camp, or at least quote them? What
software became faster/better because of tmpfs? Just some popular software
that anybody can run and say "wow, it's twice faster with /tmp on tmpfs".
None, then why forcing it?
> Maybe we need to distinguish not on size, but on speed of access, and
> have /tmp for "fast" access and a separate location for slower
> disc-backed storage
Why do you call /tmp on tmpfs "fast"? Does it make anything faster?
If not then what's the point in reinventing /tmp in a separate location?
> [As an ironic aside, when testing RAMTMP=no in rcS for backward
> compatibility for #674517, I ran out of space on /tmp and broke
> gcc/ld. On my system, there's only a few hundreds of MiB free on
> the rootfs; tmpfs is absolutely needed here!]
Ehm... A few questions, I'm just curious:
1. Don't you use -pipe option for gcc?
2. How have you managed to fill "a few hundreds of MiB" with gcc!?
3. What do you think about default RAMTMP=auto idea: in addition to the
RAMTMP=no and RAMTMP=yes implement RAMTMP=auto value: mounting /tmp to
tmpfs only when this increases free space in /tmp? Meaning, if you have
more than 20%VM free space in /tmp on disk, than no tmpfs mounted
(the "Idea: mount /tmp to tmpfs depending on free space and RAM" mail)?
It would solve the problem of small root and at the same time all the
"tmpfs problems" will go away.
--
Serge
Reply to: