On Fri, 2012-06-01 at 12:18 -0400, DJ Delorie wrote: > I'm going to chime in once to add my thoughts... It's already way too > late for me to influence the decision (first I heard of it is "it's > decided") so my only recourse is to add it to the long list of things > I have to "undo" after installing Fedora. > > > Sorry guys, this feature sucks. > > +1 on this feature sucks. Perhaps not for the same reasons. It's > mostly for this one:
The more I think of it the more I tend to +1 as well. > > And how is a random user supposed to know this? They won't [..] > These choices are being made without "empowering the users" at all, > since the changes happen without warning them, advising them, or > letting them choose beforehand. IMHO this is the wrong way to do it. I am not sure asking is the right thing, I think tmpfs in RAM should be an *optional* supporte dfeature for those users that have a workload that *will* benefit from this feature and therefore *will* seek it. By all means make it easy to enable it in some config file or even GUI, but setting it up by default seem to be misguided. > My system is already maxxed out on RAM, I can't buy any more, and > *yes* I need that RAM to be process RAM: > > total used free shared buffers cached > Mem: 24739484 19815180 4924304 0 4600752 1428024 > -/+ buffers/cache: 13786404 10953080 > Swap: 2056312 816072 1240240 > > > With /tmp in RAM, it's not flushed at _boot_, but at _shutdown_ > > Losing /tmp on system crashes makes it harder to diagnose them, if > there's information in /tmp relevent to the crash. There have been > *lots* of time I've gone digging through /tmp looking for some interim > file that turned out to be not so temporary. Indeed. > > Just add the space that you would have used for /tmp to your swap. > > My /tmp (/) is 1.2TB (It will be 3TB after this weekend's upgrade). > It's unrealistic to add that much swap. Yes, I've had times when I > need lots of /tmp space, and I don't want to flush my I/O buffers or > running programs to get it. I/O buffers are more important to me than > /tmp speed. Same here. > Has anyone even compared the performance of tmpfs-on-swap vs > tmp-on-ext? I'm contemplating *removing* my swap because the system > slows to a crawl anytime swap is needed. If tmp is on swap, how is > process performance affected? I do occasionally run swapoff -a I do that when I *know* the system is trashing just because the kernel is caching a lot of crap and swapping out a working set that *do* fit completely in memory if it weren't for the stupidly overly aggressive buffer caches. Having more than a few Gig of swap, esp on rotatory media is just suicide, and forcing to use swap for /tmp files seem to be really the wrong way to go *as a default* > > The *default* limit for tmpfs is half of physical RAM > > I.e. the default limit on tmpfs is to make half your RAM unavailable > to programs and buffers. Given how bloated software is becoming > (Fedora is no exception), this is a step backwards. On my 'normal' systems once the desktop is fully started with Firfox, Gnome, Evolution and all the crap, I already am using more than half the RAM available, so tmpfs in RAM means I hit swap as soon as something decides to write a tmp file as if we didn't have enough I/O issues with latest kernels in Fedora, isn't that awesome ? Not! > In conclusion, /tmp on tmpfs is a non-starter for me, and will be > changed on my systems as soon as possible. The risk here is that people will try to build on the fact /tmp is tmpfs by default, already Lennart hinted tmpfs has nice side effects from his pov, how soon before /tmp on real disk will cause some features not to work ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
