On Wednesday 28 Mar 2012 16:38:38 Jos Poortvliet wrote:
In short, I would STRONGLY recommend against mounting /tmp tmpfs. That ONLY works for advanced users as they can fix the resulting problems themselves. Anyone who keeps their PC on for a longer period of time will see that folder grow and grow and grow. Eating memory instead of diskspace is bad in itself, running out of space there is worse...
That's not the pattern of usage for a tmpfs /tmp that I see. I'm certainly not a lightweight user and usually run with longish uptimes between the kernel updates. At home I have my /tmp tmps limit at 1GB on my 16GB system, the 8GB & 4GB systems run 512MB & 256MB respectively. I use the largest RAM machine as my main workstation. I don't currently set /tmp to be tmpfs on servers, but I plan to in future. Currently on the largest RAM machine that I use as my main workstation, with a modest 27 days up /tmp is consuming 179MB, with 173MB of that being chromium cache. In practice I find *most* software and scripts behave very well in how they use /tmp. I've been using tmpfs /tmp since 11.3 and It's true, once or twice that I can remember, I have had software not work correctly because /tmp was full. The first occasion was from watching a long Flash video in Firefox. The second occasion was either Audacity or Spotify filling /tmp as it's scratch disk. The flash problem went away when I stopped browsing with Firefox and switched to Chromium. The second problem was of course trivially fixable, all reasonable applications that might use a large scratch disk have easily configurable scratch locations in the options/preferences. Of course these two times when software failed due to a full /tmp are in my opinion much preferable to the alternative. The alternative is that when /tmp is a physical volume and badly behaved software fills the whole volume (usually the / volume as well) the whole system is brought to it's knees. This has happened to me often enough from badly written scripts, bugs or software and is the main reason I started using tmpfs /tmp. One other side thing, which might be nice for some users, is sometimes noticable performance benefit from having caches (including browser cache) in tmpfs /tmp. The other benefit I am looking forward to, if we progress far enough with the "/usr" move, is read only / , and so tmpfs /tmp to me makes perfect sense. So in summary I agree with what most people want. Lets *not* introduce any *surprises* on upgrade and if we can make this sensibly configurable too outside of any defaults on a new install (if we go down this route). However I think it does make sense (with tangible benefits) to consider tmpfs /tmp for most desktop users. Lets face it, if you're a power user who is going to be using _large_ amounts of /tmp due to scripts, data manipulation, compiling or using "power apps", you're more than capable of configuring your system to compensate. I see Firefox + Flash as an issue on this though, what can we do about that? Cheers the noo, Graham -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org