Re: Action required: Rawhide: /tmp is now on tmpfs
On 02/06/12 00:05, Tomas Mraz wrote: But that is a pretty bad situation isn't it? And it really is not so rare situation unless users would really know not to do that. If, for the sake of discussion, I suppress my conservative instincts and start thinking about How the ideal OS in the ideal world should work (which is a very bad idea, IMHO, but anyway), I am still thinking about this from https://fedoraproject.org/wiki/Features/tmp-on-tmpfs#Comments_and_Discussion: We believe that /etc/fstab is the place to configure real file systems, for actual user data, backed by real devices. The API file system /tmp does not qualify for that in our eyes. /tmp is very much something that should just exist as part of the OS and needs no user configuration. Isn't it really just our bad habit, that we work too much outside of $HOME? Shouldn't whole world outside of $HOME be for a normal user just a black box (so no movies there)? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Am 02.06.2012 04:08, schrieb Jesse Keating: On 06/01/2012 09:04 AM, Reindl Harald wrote: no, you do NOT want swap-usage in most workloads at all The useless 2G file will get swapped out, not important things that are actively being used in ram it does not matter WHAT get swapped out from the moment on the system starts to swap performance sucks my co-developer has even troubles working with eclipse while firefox/thunderbird on KDE is running on a notebook with 4 GB memory because after some hours the machine starts to swap and get partly unresponsable and now the default will add additional memory pressure? well, do what you want, as said i am able to fix such misconfigurations, but stop believe such features are good for the majority of userbase signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 10:28 PM, Reindl Harald h.rei...@thelounge.net wrote: it does not matter WHAT get swapped out from the moment on the system starts to swap performance sucks This is what I meant about being dogmatic up thread. You're being a anti-swap zealot here. Yes, using swap is slow. It's slow because using the disk is slow. If you are using the disk because tmpfs is being written out, or because your tmpfs is just a file system is the same thing. Tmpfs just has the advantage of minimizing the disk activity— both in cases where none is needed, and in cases where it is. Really, you should try it. It works very well and does not make your machine perform poorly, even when under memory pressure. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Once upon a time, Reindl Harald h.rei...@thelounge.net said: Am 02.06.2012 04:08, schrieb Jesse Keating: The useless 2G file will get swapped out, not important things that are actively being used in ram it does not matter WHAT get swapped out from the moment on the system starts to swap performance sucks With /tmp-on-storage, that 2G file would have already caused a large amount of I/O; it is the same 2G being written on to the same storage, whether a /tmp filesystem or swap. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Am 02.06.2012 19:24, schrieb Gregory Maxwell: Tmpfs just has the advantage of minimizing the disk activity— both in cases where none is needed, and in cases where it is. you refuse to understand if some app creates a 2 GB file in /tmp and does not remove your only pressure is to the page-cache which is not the same as start swapping because memory pressure Really, you should try it. It works very well and does not make your machine perform poorly, even when under memory pressure it have used tmpfs probably long before you even knew it exists (on some workloads even for /tmp) but it is not the holy grail for each workload and so a wrong DEFAULT Am 02.06.2012 19:25, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: Am 02.06.2012 04:08, schrieb Jesse Keating: The useless 2G file will get swapped out, not important things that are actively being used in ram it does not matter WHAT get swapped out from the moment on the system starts to swap performance sucks With /tmp-on-storage, that 2G file would have already caused a large amount of I/O; it is the same 2G being written on to the same storage, whether a /tmp filesystem or swap you refuse to understand the difference WHEN this happens writing 2 GB to disk on modern fileystems is meaningless having the 2 GB in memory and a by the introduced memory pressure swapped out application get the focus and allocate a large amount of memory while loading large data you have MULTIPLE pressure * relaod the application form swap * load application data from disk * write /tmp and/or other data to disk so you have THREE heavy disk usage patterns with mixed read and write - have fun with your coffee again: there may be workloads where it is nice and a small improvement as i have some of them by my self but that does NOT qulify it as a os-wide default signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 1:15 AM, Sergio Durigan Junior sergi...@redhat.com wrote: On Thursday, May 31 2012, Ralf Corsepius wrote: So I'll patch sort to default to /var/tmp rather than /tmp. Please don't. As many pointed out, there are many disadvantages in doing this, and I really do not think we should be fixing (sic) our apps because of such a controversial feature. `sort' and other programs have been working right like this for *years*; introducing such change would mean please give me more bugs, as Ralf pointed out. To remind everyone about the state of this change: * It was approved by FESCo for Fedora 18 * It was implemented Therefore, it is reasonable to assume that Fedora 18 will ship with this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. So, please, if you are a package maintainer, for each package: 1. (fedpkg prep) 2. (grep -irl 'te\?mp' .) 3. Manually review the results for code that could be broken by making /tmp a tmpfs 4. Prepare patches, and either get them accepted upstream, or add them to your Fedora package. If you are anyone: Please suggest improvements to the instructions above to reduce the number of false positives. If you are the feature owners: Please read through all of the previous discussions mentioning specific things that would be broken, and file the bugs yourselves - don't rely on the single person out of thousands to have read the e-mail. If you don't like the change: Sorry. I don't like the change either, but now we need focus on making Fedora 18 less broken. Alternatively, you could ask FESCo to reconsider - but before doing so, please review the FESCo meeting minutes from April 4 and the following devel@ threads, and make sure you have _new_ arguments. Repeating things that were already raised is unlikely to persuade FESCo. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 01:21:25PM +0200, Miloslav Trmač wrote: Therefore, it is reasonable to assume that Fedora 18 will ship with this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. I was using /tmp on tmpfs (with $TMPDIR poining inside of /tmp) for several years in ALT Linux. And by use I mean build packages using mock-like tool that creates chroots in $TMPDIR. During all these years, my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. Having /tmp on tmpfs is not THAT scary, is you ask me... -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 08:12 AM, Alexey I. Froloff wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? So if things start acting up the answer is to add more swap and mess with fstab? WTF? So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Sorry guys, this feature sucks. The rationale was and is handwavy at best and none of the legitimate concerns which have been raised have been answered in any meaningful fashion. There have never been any numbers showing the IO/power benefit claims are true. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Brian Wheeler wrote: And how is a random user supposed to know this? So if things start acting up the answer is to add more swap and mess with fstab? WTF? So now any software which uses /tmp for gasp temporary space is now potentially broken depending on the size of the temporary data. Sorry guys, this feature sucks. The rationale was and is handwavy at best and none of the legitimate concerns which have been raised have been answered in any meaningful fashion. There have never been any numbers showing the IO/power benefit claims are true. +1, /tmp on tmpfs is NOT helpful. (That said, we have even bigger problems coming up with Restricted (Secure) Boot!) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 02:12 PM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 01:21:25PM +0200, Miloslav Trmač wrote: Therefore, it is reasonable to assume that Fedora 18 will ship with I certainly disagree ... this change is not reasonable. this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. I was using /tmp on tmpfs (with $TMPDIR poining inside of /tmp) for several years in ALT Linux. And by use I mean build packages using mock-like tool that creates chroots in $TMPDIR. During all these years, my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. Having /tmp on tmpfs is not THAT scary, is you ask me... If you ask me (I did the same for some time (Fedora 13-14 era) ) the typical symptoms of /tmp on tmpfs are sporatic, non-deterministic malfunctions. I guess is, struggling with these sporadic malfunction will become an FAQ. Finally, using /var/tmp instead of /tmp for temporary files (c.f. the sort case in another thread) contradicts the primary purpose of /tmp on tmpfs: *speed* In other words, moving current /tmp use-cases to /var/tmp will not gain you any speed-wise. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 02:47 PM, Ralf Corsepius wrote: On 06/01/2012 02:12 PM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 01:21:25PM +0200, Miloslav Trmač wrote: Therefore, it is reasonable to assume that Fedora 18 will ship with I certainly disagree ... this change is not reasonable. this change, and applications need to be updated to handle the change, or we will have a more broken Fedora 18. Advising people not to patch programs won't make Fedora 18 less broken at this point. I was using /tmp on tmpfs (with $TMPDIR poining inside of /tmp) for several years in ALT Linux. And by use I mean build packages using mock-like tool that creates chroots in $TMPDIR. During all these years, my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. Having /tmp on tmpfs is not THAT scary, is you ask me... If you ask me (I did the same for some time (Fedora 13-14 era) ) the typical symptoms of /tmp on tmpfs are sporatic, non-deterministic malfunctions. I guess is, struggling with these sporadic malfunction will become an FAQ. Finally, using /var/tmp instead of /tmp for temporary files (c.f. the sort case in another thread) contradicts the primary purpose of /tmp on tmpfs: *speed* In other words, moving current /tmp use-cases to /var/tmp will not gain you any speed-wise. Not all /tmp user-cases need to move to /var/tmp sort is special in this regard in that it only uses external files when there isn't enough RAM. I.E. is expects it to be slower (larger). cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? In Soviet ALT Linux we didn't care about random users ;-) In perfect world random user must be smart enough to read the documentation. However, this implies, that such documentation exists and easily accessed (which at first sight is true for Fedora). So if things start acting up the answer is to add more swap and mess with fstab? WTF? This is up to Release Managers. Reasonable defaults in installer, documentation, etc... So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. You can always point it to $HOME/tmp for example. And you can always turn it off if you really need to. Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 10:23 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? In Soviet ALT Linux we didn't care about random users ;-) In perfect world random user must be smart enough to read the documentation. However, this implies, that such documentation exists and easily accessed (which at first sight is true for Fedora). So if things start acting up the answer is to add more swap and mess with fstab? WTF? This is up to Release Managers. Reasonable defaults in installer, documentation, etc... So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. You can always point it to $HOME/tmp for example. And you can always turn it off if you really need to. Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default. Since most user don't know anything about this why not leave it off and the sophisticated power user can turn it on, since It is trivial to do. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 10:23 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 09:27:16AM -0400, Brian Wheeler wrote: my biggest problem was that tmpfs by default allocates half of physical RAM for partition. So I just allocated big enough swap and added a line to /etc/fstab with appropriate size= option. And how is a random user supposed to know this? In Soviet ALT Linux we didn't care about random users ;-) So that means that random users care about YOU! In perfect world random user must be smart enough to read the documentation. However, this implies, that such documentation exists and easily accessed (which at first sight is true for Fedora). Sure. When there's mystery problems , who is going to think oh yeah, /tmp is in ram now and chrome just wrote a big temp file...better go look up how to add swap? I'm going to guess 'nearly nobody' So if things start acting up the answer is to add more swap and mess with fstab? WTF? This is up to Release Managers. Reasonable defaults in installer, documentation, etc... The thing is, the amount of reasonable swap is now not a function of just RAM overflow but also /tmp usage -- which is something that can vary dramatically at runtime. So now any software which uses /tmp for *gasp* temporary space is now potentially broken depending on the size of the temporary data. Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. You can always point it to $HOME/tmp for example. And you can always turn it off if you really need to. Sure, no software _should_ use it directly, but it happens a lot...and not in packages which are in the repo: home grown and third party. Additionally, there's 20+ years of habit to break for a lot of people and that's not something you can easily patch. Running things like grep \\ 404\ apache.log /tmp/404s.log is pretty ingrained for many people. I'll probably turn it off because I've been down this road with Solaris and it sucked. I will grant that the linux implementation is better, but I want RAM to be used for the running software and if its not being used for that, caching what's actively being used. Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default. Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 03:35:45PM +0200, Kevin Kofler wrote: (That said, we have even bigger problems coming up with Restricted (Secure) Boot!) To be fair, this problem is not one of our own doing. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 01, 2012 at 11:31:21AM -0400, Brian Wheeler wrote: Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. And tmpfs is faster than any other filesystem, and easily resized both ways. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Am 01.06.2012 16:23, schrieb Alexey I. Froloff: Sorry guys, this feature sucks. I like this feature, and there should be easy, well documented way to turn it off. I personally don't see a reason why it should be off by default so you can add 1 line to /etc/fstab since many years this feature is another having solution, searching for problem DO NOT SPIT USELESS DATA IN MY RAM PER DEFAULT BECAUSE RAM IS EXPENSIVE STORAGE AND USED FOR BETTER THINGS but why forcing majority of users do the same to get a usefull behavior? it is not smart to waste RAM with temp-data and force every software with large temp-data to get fixed write it somewhere else Well, no software should use /tmp directly, IMO. There's nice environment variable $TMPDIR. what does this change? finally most software will be fixed to not use it at all and spit in /var/tmp and render /tmp useless for many years it was a perfect setup to make a own partition or use in case of virtual machines even a own vdisk for /tmp because there can be large data which you do not want on a 4 GB small / and now the defaults are changed to spit tmp-data in the root-fs yes, powerusers can change this (and will) as also they could use tmpfs all over the time - but it is a wrong DEFAULT signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Am 01.06.2012 17:52, schrieb Alexey I. Froloff: One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. and exatly the opposite happens for systems which are well designed and have a seperate /tmp because as side-effect of this feature all osrt of applications are patched to spit their stuff to /var/tmp and back to rootfs does nobody of the feautre owners realize that this is not smart nor bring any benefit at all? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:52 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 11:31:21AM -0400, Brian Wheeler wrote: Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. And tmpfs is faster than any other filesystem, and easily resized both ways. Has anyone even done any real testing of this across the spectrum of installation types? How is this going to affect VM installations where RAM and swap is usually very minimal levels? 256mb or 512mb in many instances. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Once upon a time, Reindl Harald h.rei...@thelounge.net said: DO NOT SPIT USELESS DATA IN MY RAM PER DEFAULT BECAUSE RAM IS EXPENSIVE STORAGE AND USED FOR BETTER THINGS Actually, the data written to /tmp _always_ goes through the page cache and is held in RAM (at least for a bit). Since many things in /tmp are short-lived, they'll stay in the page cache for life. The difference between /tmp-on-storage and /tmp-on-tmpfs is that tmpfs has no overhead for reading metadata from storage, allocating space, flushing updated metadata, etc.; the files just only exist in the same page cache they would have been in all along. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
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: And how is a random user supposed to know this? I think any time we make a fundamental change without making the user aware of this change and CHOOSING it, we have failed the user. How to fix this? I don't know, but perhaps... * Install should ask the user what they want. Since /tmp needs to be set up early, it needs to be done in initrd anyway. * some post-install GUI/TUI that says the following systematic changes are now available, please decide if you want them * other ideas A note from the About Fedora web page: We also believe in empowering others to . . . 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. It seems to me this is part of a larger pattern: Fedora (or upstream) announces that some major change has been decided. There is a heated debate over whether it was a good idea or not. Nothing changes. Is this the new Fedora process? Force change on users then ignore their complaints? That seems to be my Fedora-user experience. Also, anyone who says they should read the documentation is delusional. They don't read it. So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. 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 sharedbuffers cached Mem: 24739484 198151804924304 046007521428024 -/+ buffers/cache: 13786404 10953080 Swap: 2056312 8160721240240 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. 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. 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? 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. In conclusion, /tmp on tmpfs is a non-starter for me, and will be changed on my systems as soon as possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:52 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 11:31:21AM -0400, Brian Wheeler wrote: Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. Wouldn't the things which modify important stuff in / be running as root? If so, they'd get that 5% to play with. In any case, I see your point. However, I can't say that it has happened to me since the days of 32M roots :) And tmpfs is faster than any other filesystem, and easily resized both ways. Not really, though. You have to muck with adding and removing swap partitions if you have workload that is biggish. I keep a 2G swap on all of my systems so /tmp as tmpfs is going to do poorly on them and since the disk is pretty much allocated elsewhere I can't just move files around to get more /tmp (or / if things are going wonky). How would an upgrade deal with that situation? Its very much like the traditional commercial unixes which would have a separate filesystem for everything: free space was never in the place where you actually needed it. I'll grant that tmpfs is faster than other filesystems, but is it a win on a real workload? I haven't seen anyone answer that. It seems like this feature is trading a set of well-known problems for a different set of problems without a killer reason. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
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 sharedbuffers cached Mem: 24739484 198151804924304 046007521428024 -/+ buffers/cache: 13786404 10953080 Swap: 2056312 8160721240240 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
Re: Action required: Rawhide: /tmp is now on tmpfs
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. It could have been as easy as a checkbox in the disk partitioning screen of the install: [ ] Use RAM and swap for temporary files Perhaps checked/unchecked/disabled via some logic (enough ram? swap enabled? some /tmp listed in fstab?) but let the user decide. 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. echo 1 /proc/sys/vm/swappiness -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 1:02 PM, Simo Sorce s...@redhat.com wrote: 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! No. Thats not what it means. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 03:55 PM, Pádraig Brady wrote: Not all /tmp user-cases need to move to /var/tmp sort is special in this regard in that it only uses external files when there isn't enough RAM. I.E. is expects it to be slower (larger). Would you mind debating if anything else is special? # strings /usr/bin/*|grep ^/tmp$|wc -l 361 -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
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: And how is a random user supposed to know this? I think any time we make a fundamental change without making the user aware of this change and CHOOSING it, we have failed the user. How to fix this? I don't know, but perhaps... * Install should ask the user what they want. Since /tmp needs to be set up early, it needs to be done in initrd anyway. * some post-install GUI/TUI that says the following systematic changes are now available, please decide if you want them http://gnomememes.tumblr.com/post/23820002746/it-should-at-least-be-made-an-option#notes General Notice: from now on I am going to use that picture as shorthand for the following screed. This is a terrible terrible idea, and the reason why has been reasonably well-understood by several Fedora groups for some time now (I'd cite especially desktop, anaconda, and QA. Boy howdy, QA knows all about it). Every time we 'at least make it an option' we double the complexity of the entire path in question. Double the complexity means double the maintenance headache, double the QA headache, and at least double the bugs. If we go around making every significant change to distro policy optional in the installer, how many questions are you going to be bombarded with at upgrade time over the years? On a system that's been upgraded three times, how many permutations of $SIGNIFICANT_CONFIGURATION_CHOICE can we now reasonably expect people to have in place and thus have to test for? How many additional code paths have we added to the installer (god knows it has enough already; so many that dlehman and mizmo are having regular Brain Explodey Syndrome lately just trying to _whiteboard_ the damn thing). It's this kind of 'everything should be a choice' crap that gives us hugely overcomplex codebases like anaconda which we can never, realistically, fully test ever again. (No disrespect to anaconda team intended; now we've got it, we're stuck with it.) It's also what regularly gets Microsoft into the soup, and they have development and QA resources that utterly dwarf ours. I can see arguments both ways on whether /tmp-on-tmpfs should be our default and supported config, to be honest. I don't mind whether we go ahead with the feature or revert it. But we absolutely shouldn't be asking people whether they want it or not in the installer, and so implicitly having two equally-supported 'default configs'. That way madness lies. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 01/06/12 15:27, Brian Wheeler wrote: And how is a random user supposed to know this? He is not and he doesn't have to know it. I have been using for couple of years /tmp on tmpfs, just with tmpfs/tmptmpfs defaults,nosuid,nodev 0 0 and aside from a situation when I tried to save couple of giga large move file there (which got my system to an interesting state of system load 25 before it finally decided that there is not enough space on /tmp) I have never encounter any issues. Notice how weird requirements Mirek did on the system. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
Am 01.06.2012 18:01, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: DO NOT SPIT USELESS DATA IN MY RAM PER DEFAULT BECAUSE RAM IS EXPENSIVE STORAGE AND USED FOR BETTER THINGS Actually, the data written to /tmp _always_ goes through the page cache and is held in RAM (at least for a bit). Since many things in /tmp are short-lived, they'll stay in the page cache for life. The difference between /tmp-on-storage and /tmp-on-tmpfs is that tmpfs has no overhead for reading metadata from storage, allocating space, flushing updated metadata, etc.; the files just only exist in the same page cache they would have been in all along but the data in /tmp are not forever in the cache if it is tmpf and app dies after creating a 2 GB file in /tmp RAM will be filled until next reboot and leads sooner or later in swap-usage or OOM-killer no, you do NOT want swap-usage in most workloads at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, 2012-06-01 at 22:13 +0200, Matej Cepl wrote: On 01/06/12 15:27, Brian Wheeler wrote: And how is a random user supposed to know this? He is not and he doesn't have to know it. I have been using for couple of years /tmp on tmpfs, just with tmpfs/tmptmpfs defaults,nosuid,nodev 0 0 and aside from a situation when I tried to save couple of giga large move file there (which got my system to an interesting state of system load 25 before it finally decided that there is not enough space on /tmp) I have never encounter any issues. Notice how weird requirements Mirek did on the system. Matej, how often do you reboot your machine ? Do you ever hybernate ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On Fri, 2012-06-01 at 22:13 +0200, Matej Cepl wrote: On 01/06/12 15:27, Brian Wheeler wrote: And how is a random user supposed to know this? He is not and he doesn't have to know it. I have been using for couple of years /tmp on tmpfs, just with tmpfs/tmptmpfs defaults,nosuid,nodev 0 0 and aside from a situation when I tried to save couple of giga large move file there (which got my system to an interesting state of system load 25 before it finally decided that there is not enough space on /tmp) I have never encounter any issues. Notice how weird requirements Mirek did on the system. But that is a pretty bad situation isn't it? And it really is not so rare situation unless users would really know not to do that. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
