Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
For details please see this feature page:
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs
If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default.
This will most likely lead to a problem or two with software that isn't happy about /tmp being small. We have created a tracker bug to keep track of this:
https://bugzilla.redhat.com/show_bug.cgi?id=826015
If you have identified a bug that is triggered by /tmp being on tmpfs now, please add it to this tracker bug!
For a bit of background on all of this and recommendations for developers, please see:
http://0pointer.de/blog/projects/tmp.html
Thank you,
Lennart
On May 30, 2012 5:41 PM, "Lennart Poettering" mzerqung@0pointer.de wrote:
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
For details please see this feature page:
Thanks for the heads-up!
If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default.
What does an fstab entry that means, "leave /tmp on the / filesystem," look like?
On Wed, 30.05.12 19:04, Garrett Holmstrom (gholms@fedoraproject.org) wrote:
If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default.
What does an fstab entry that means, "leave /tmp on the / filesystem," look like?
See the feature page.
To turn this feature off, do:
systemctl mask tmp.mount
Lennart
On 05/31/2012 12:18 PM, Lennart Poettering wrote:
On Wed, 30.05.12 19:04, Garrett Holmstrom (gholms@fedoraproject.org) wrote:
If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default.
What does an fstab entry that means, "leave /tmp on the / filesystem," look like?
See the feature page.
To turn this feature off, do:
systemctl mask tmp.mount
Lennart
Is enough to edit /etc/fstab? If not, why? Any benefits to have it directly in systemd?
RR
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
[...]
This will most likely lead to a problem or two with software that isn't happy about /tmp being small.
For example "sort".
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
[...]
This will most likely lead to a problem or two with software that isn't happy about /tmp being small.
For example "sort".
This is a good example because `sort` algorithmically needs something below RAM in the memory hierarchy (i.e. bigger), but with the same persistence characteristics of /tmp.
Currently `sort` defaults to $TMPDIR or if not set '/tmp'.
Now /var/tmp should be "more persistent" which we don't need, but shouldn't be an issue, but should also not be in RAM and so is more appropriate.
So I'll patch sort to default to /var/tmp rather than /tmp.
I'm a little worried about the general availability of /var/tmp. I know I've created distros without it at least.
For my own reference, sort does support a list of tmp dirs, but it'll need to be tweaked to support non existent dirs:
$ seq 100000 | sort -T /foo -T /tmp -S1M sort: cannot create temporary file in `/foo': No such file or directory
`tac` from coreutils also needs a similar patch.
cheers, Pádraig.
On 05/31/2012 12:45 PM, Pádraig Brady wrote:
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
[...]
This will most likely lead to a problem or two with software that isn't happy about /tmp being small.
For example "sort".
This is a good example because `sort` algorithmically needs something below RAM in the memory hierarchy (i.e. bigger), but with the same persistence characteristics of /tmp.
Currently `sort` defaults to $TMPDIR or if not set '/tmp'.
Which is the correct place to use.
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
So I'll patch sort to default to /var/tmp rather than /tmp.
This would mean introducing a bug.
I'm a little worried about the general availability of /var/tmp.
Also consider the case of /var/tmp being a symlink to /tmp.
This was the default for some Linux variants for many years which still can be found on many systems.
Ralf
On Thu, May 31, 2012 at 12:55:28PM +0200, Ralf Corsepius wrote:
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
Well, not just FHS, but "traditional" usage within Red Hat and Fedora. For as long as I can remember, /tmp has had a 10-day retention and /var/tmp 30-day.
Does that matter?
On Thu, 31.05.12 08:51, Matthew Miller (mattdm@mattdm.org) wrote:
On Thu, May 31, 2012 at 12:55:28PM +0200, Ralf Corsepius wrote:
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
Well, not just FHS, but "traditional" usage within Red Hat and Fedora. For as long as I can remember, /tmp has had a 10-day retention and /var/tmp 30-day.
Does that matter?
We still have 10d and 30d clean-up for that. With one addition though: /tmp is also flushed on reboot.
Lennart
On 05/31/2012 08:59 AM, Lennart Poettering wrote:
On Thu, 31.05.12 08:51, Matthew Miller (mattdm@mattdm.org) wrote:
On Thu, May 31, 2012 at 12:55:28PM +0200, Ralf Corsepius wrote:
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
Well, not just FHS, but "traditional" usage within Red Hat and Fedora. For as long as I can remember, /tmp has had a 10-day retention and /var/tmp 30-day.
Does that matter?
We still have 10d and 30d clean-up for that. With one addition though: /tmp is also flushed on reboot.
Lennart
I'm still unsure what the point of this "feature" really is.
The wiki page lists the features as:
* By implementing this we, by default, generate less IO on disks. This increases SSD lifetime, saves a bit of power and makes things a bit faster.
Do we have actual numbers for this? It would seem like we already have this with ext4's deferred allocation and the pagecache.
* /tmp is automatically flushed at boot.
It seems like adding an rm to the startup sequence would do this with less surprises.
* We bring Fedora closer to commercial Unixes and other Linux distributions.
Um, so? Any solaris admin worth their salt kills the ram-based /tmp as soon as the install is finished. Its been that way since the 90's.
* We make the delta to stateless read-only systems smaller.
Why is this a win for the normal user?
The page says the user experience should barely change -- which I think is really downplaying the scope of this change.
Firstly, the cleanup of /tmp on reboot is a behavior change that is going to bite a lot of people, no matter how bold and large it appears in the release notes. This isn't terribly controversial, but it still sucks for those who get hit by it.
More importantly, the restriction that /tmp be used for files that are less than an installation-defined size is going to cause a lot of problems. Patching everything to use /var/tmp because we don't know how big the data file is going to be in advance just moves the problem somewhere else and doesn't solve anything. There are going to be mystery "disk full" messages and issues on low memory machines.
So why are we doing this again? How is this a benefit to the normal user?
At the most, this should be an opt-in feature rather than the default.
Brian
On 05/31/2012 09:27 AM, Brian Wheeler wrote:
On 05/31/2012 08:59 AM, Lennart Poettering wrote:
- We bring Fedora closer to commercial Unixes and other Linux distributions.
Um, so? Any solaris admin worth their salt kills the ram-based /tmp as soon as the install is finished. Its been that way since the 90's.
Yes, so we too can be just like everyone else and have to kill the ram-based /tmp as soon as install finishes.
On Thu, May 31, 2012 at 09:27:03AM -0400, Brian Wheeler wrote:
The wiki page lists the features as:
[...]
- /tmp is automatically flushed at boot.
It seems like adding an rm to the startup sequence would do this with less surprises.
Wait, hold on a sec. Again, not necessarily a problem but we should be clear on this. With /tmp in RAM, it's not flushed at _boot_, but at _shutdown_ (clean or not). That may be detrimental to fixing problems (like surprise reboots). The benefit may be worth that downside but we should at least document the distinction.
I'm going edit the wiki but I'm not sure what exact wording should be. I guess the *benefit* is "clean /tmp on boot" and discussion of the implication should be elsewhere -- the user experience section, I think.
The page says the user experience should barely change -- which I think is really downplaying the scope of this change.
Right. I made some edits there.
On Thu, May 31, 2012 at 02:59:09PM +0200, Lennart Poettering wrote:
Well, not just FHS, but "traditional" usage within Red Hat and Fedora. For as long as I can remember, /tmp has had a 10-day retention and /var/tmp 30-day. Does that matter?
We still have 10d and 30d clean-up for that. With one addition though: /tmp is also flushed on reboot.
I know, but if people who want something not-ram-backed are switching to /var/tmp, they're _also_ getting this different clean-up behavior as a side-effect. (Different in that it went from 10 to 30.)
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.
That's crazy.
.
On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno greno@verizon.net wrote:
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. That's crazy.
Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap.
Am 01.06.2012 17:05, schrieb Gregory Maxwell:
On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno greno@verizon.net wrote:
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. That's crazy.
Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap
well designed machines do NOT swap and have not alligend swap at all - in the case of virtualization you MUST NOT enforce swapping if you really like perofrmance
even in 100 years there will be installations of people having 50,80,100 or more vurtual machine son a host and try to allocate only needed ressourcs
wasting RAM a a default is only bad in such cases
but however, since most packagers starting to move all their temp stuff to /var/tmp we well not noitice any changes except that you have to mount the tmp-vdisk to /var/tmp istead /tmp
On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald h.reindl@thelounge.net wrote:
well designed machines do NOT swap and have not alligend swap at all - in the case of virtualization you MUST NOT enforce swapping if you really like perofrmance
I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)
The dogmatic 'swap is bad for performance' is justified only because writing/reading a slow disk is bad for performance.
Tmpfs helps your system avoid disk i/o by giving your system more flexibility in how it manages all of the available temporary space.
It's something that people who are very concerned with swap impact on performance should appreciate greatly.
Am 01.06.2012 18:26, schrieb Gregory Maxwell:
On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald h.reindl@thelounge.net wrote:
well designed machines do NOT swap and have not alligend swap at all - in the case of virtualization you MUST NOT enforce swapping if you really like perofrmance
I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)
The dogmatic 'swap is bad for performance' is justified only because writing/reading a slow disk is bad for performance.
and how does /tmp in RAm change this?
it enforces swapping because temporary files are held completly in memory and if they are large enough and your workload needs active RAm you enforce swapping
if they are on disk under /tmp they are cached only as long page-cache or active RAM is not needed for the workload and the memory can be released instead WRITE it do disk with swapping
Tmpfs helps your system avoid disk i/o by giving your system more flexibility in how it manages all of the available temporary space
how should this work? not in the real life!
On Fri, Jun 1, 2012 at 12:32 PM, Reindl Harald h.reindl@thelounge.net wrote:
I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)
The dogmatic 'swap is bad for performance' is justified only because writing/reading a slow disk is bad for performance.
and how does /tmp in RAm change this?
it enforces swapping because temporary files are held completly in memory and if they are large enough and your workload needs active RAm you enforce swapping
They are not held 'completely' in memory. The kernel can choose where to store them based on the current demands on the system. It can store them on disk (though more cheaply than other FSes because it doesn't have to worry about it being recoverable across a reboot) or in memory.
if they are on disk under /tmp they are cached only as long page-cache or active RAM is not needed for the workload and the memory can be released instead WRITE it do disk with swapping
This is how tmpfs works too, except without tmpfs some write activity is required because the metadata updates (and data for sufficiently long lived tmp files) will be written to disk. So what the normal buffer cache does for reading tmpfs lets it also do for writing.
On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald h.reindl@thelounge.net wrote:
- it is a valid workload that a application creates a 10 GB tempfile
- ok, you say: use /var/tmp
- well, i say: my whole rootfs is only 4 GB and 2 Gb are used
If your rootfs wasn't big enough for your tmp workload you would have had to have had a separate tmp partition. Either continue to use it— or mount it as swap and set size= to allow you to use it in tmp.
It works great.
On Fri, Jun 1, 2012 at 4:14 PM, Chris Adams cmadams@hiwaay.net wrote:
I keep seeing sort as the primary example: how often are people sorting multi-gigabyte files?
I do this sort of crazy stuff all the time. But— if I were just a random user and did that sort of stuff I'd run out of space on root in the process. I don't run out of space in tmp because I make my tmp big enough... just like I'd have to do if I wasn't using tmpfs. Weird workload require considerations, the use of tmpfs changing the default tmp size might move the weirdness boundary line around some but it doesn't make a fundamental change in that.
At the same time it'll also be a good opportunity to find and fix software that is needlessly writing enormous outputs to /tmp (which could have been problematic for all users, including doing things like causing data loss when /tmp is on the same volume as /home and filling it up causes your programs to save zero byte file).
Am 01.06.2012 22:44, schrieb Gregory Maxwell:
On Fri, Jun 1, 2012 at 12:32 PM, Reindl Harald h.reindl@thelounge.net wrote:
if they are on disk under /tmp they are cached only as long page-cache or active RAM is not needed for the workload and the memory can be released instead WRITE it do disk with swapping
This is how tmpfs works too, except without tmpfs some write activity is required because the metadata updates (and data for sufficiently long lived tmp files) will be written to disk. So what the normal buffer cache does for reading tmpfs lets it also do for writing.
no - there is a difference
page-cache is simply freed for application use at memory allocation if you run out of memory beause a large tmpfs it forces the system to use SWAP
this happens usually while a application is allocating a large amount of memory and your system is under pressure, what happens with /tmp on tmpfs causes this swap in such moments is that your whole system will be really slow
if your workload at the same time needs access to applications which are swapped out you can go to get some coffee, there is no system on this world which will not get crippled performance due high swap load
On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald h.reindl@thelounge.net wrote:
- it is a valid workload that a application creates a 10 GB tempfile
- ok, you say: use /var/tmp
- well, i say: my whole rootfs is only 4 GB and 2 Gb are used
If your rootfs wasn't big enough for your tmp workload you would have had to have had a separate tmp partition. Either continue to use it— or mount it as swap and set size= to allow you to use it in tmp.
It works great.
Part of this feature involves patching applications to write temporary files to /var/tmp instead of /tmp. Reindl's point is that this change will cause temporary files that were previously written to the /tmp filesystem that he had explicitly prepared for this purpose to instead be written to /var/tmp and fill up his / filesystem.
Am 01.06.2012 23:23, schrieb Garrett Holmstrom:
On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald h.reindl@thelounge.net wrote:
- it is a valid workload that a application creates a 10 GB tempfile
- ok, you say: use /var/tmp
- well, i say: my whole rootfs is only 4 GB and 2 Gb are used
If your rootfs wasn't big enough for your tmp workload you would have had to have had a separate tmp partition. Either continue to use it— or mount it as swap and set size= to allow you to use it in tmp.
It works great.
Part of this feature involves patching applications to write temporary files to /var/tmp instead of /tmp. Reindl's point is that this change will cause temporary files that were previously written to the /tmp filesystem that he had explicitly prepared for this purpose to instead be written to /var/tmp and fill up his / filesystem
thank you for understand and make clear what i mean
On 06/01/2012 03:23 PM, Garrett Holmstrom wrote:
On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
On Fri, Jun 1, 2012 at 12:28 PM, Reindl Haraldh.reindl@thelounge.net wrote:
- it is a valid workload that a application creates a 10 GB tempfile
- ok, you say: use /var/tmp
- well, i say: my whole rootfs is only 4 GB and 2 Gb are used
If your rootfs wasn't big enough for your tmp workload you would have had to have had a separate tmp partition. Either continue to use it— or mount it as swap and set size= to allow you to use it in tmp.
It works great.
Part of this feature involves patching applications to write temporary files to /var/tmp instead of /tmp. Reindl's point is that this change will cause temporary files that were previously written to the /tmp filesystem that he had explicitly prepared for this purpose to instead be written to /var/tmp and fill up his / filesystem.
Without getting into the specifics of whether the feature is useful or not... Part of it could be. If fstab contains a /tmp mountpoint re-write it to /var/tmp? I doubt that will make people stop talking about this feature but just a thought.
Am 01.06.2012 23:48, schrieb Nathanael D. Noblet:
On 06/01/2012 03:23 PM, Garrett Holmstrom wrote:
On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
On Fri, Jun 1, 2012 at 12:28 PM, Reindl Haraldh.reindl@thelounge.net wrote:
- it is a valid workload that a application creates a 10 GB tempfile
- ok, you say: use /var/tmp
- well, i say: my whole rootfs is only 4 GB and 2 Gb are used
If your rootfs wasn't big enough for your tmp workload you would have had to have had a separate tmp partition. Either continue to use it— or mount it as swap and set size= to allow you to use it in tmp.
It works great.
Part of this feature involves patching applications to write temporary files to /var/tmp instead of /tmp. Reindl's point is that this change will cause temporary files that were previously written to the /tmp filesystem that he had explicitly prepared for this purpose to instead be written to /var/tmp and fill up his / filesystem.
Without getting into the specifics of whether the feature is useful or not... Part of it could be. If fstab contains a /tmp mountpoint re-write it to /var/tmp? I doubt that will make people stop talking about this feature but just a thought
how would this help? no magic rewrite can fix a behavior change of the OS for sure
it would things much more complicated, unpredictable and make the OS to a sort of gambling machine - which part at which point would rewirte what and what let you come to the conclusion that it is the right way to rewrite any admin-configuration randomly?
this whole feature should be reconsidered with all it's impacts on packages and configurations and if it is really a measurable win for anybody
i am pretty sure that on most machines the change is completly meaningless, on a high count of machines it has a serious impact and the few machines where /tmp on tmpfs would be a benfit can and do configure it since years
we are speaking here about a large hange in OS behavior and must have a REALLY positive impact on most installations which is not the case
2012/6/2 Gregory Maxwell gmaxwell@gmail.com:
On Fri, Jun 1, 2012 at 11:09 AM, Reindl Harald h.reindl@thelounge.net wrote:
well designed machines do NOT swap and have not alligend swap at all - in the case of virtualization you MUST NOT enforce swapping if you really like perofrmance
I'm sorry, I couldn't quite hear you— perhaps more all-caps would help? :-)
The dogmatic 'swap is bad for performance' is justified only because writing/reading a slow disk is bad for performance.
Tmpfs helps your system avoid disk i/o by giving your system more flexibility in how it manages all of the available temporary space.
It's something that people who are very concerned with swap impact on performance should appreciate greatly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is all this discussion about performance, optimization and memory management based on some benchmarks as well, or it is only a "feels like" flame?
On Fri, Jun 01, 2012 at 11:05:26AM -0400, Gregory Maxwell wrote:
On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno greno@verizon.net wrote:
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. That's crazy.
Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap.
The *default* limit for tmpfs is half of physical RAM (swap is not counted). So *if* tmp-on-tmpfs is left at the defaults then increasing physical RAM might be necessary. I haven't bothered to look at how tmp-on-tmpfs is implemented in systemd though.
Rich.
On Fri, 01.06.12 16:19, Richard W.M. Jones (rjones@redhat.com) wrote:
On Fri, Jun 01, 2012 at 11:05:26AM -0400, Gregory Maxwell wrote:
On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno greno@verizon.net wrote:
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. That's crazy.
Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap.
The *default* limit for tmpfs is half of physical RAM (swap is not counted). So *if* tmp-on-tmpfs is left at the defaults then increasing physical RAM might be necessary. I haven't bothered to look at how tmp-on-tmpfs is implemented in systemd though.
I think most folks here really misunderstand what tmpfs is. It's not actually strictly RAM that is used for it, it's *pageable* memory after all. tmpfs is basically RAM preferred, and swap it if we are under pressure. ext3 otoh means must be on disk in the end, but cache in RAM as much as you want. The difference here is hence not really whether things go to disk eventually or not, or whether this takes away precious RAM, because both use disk and both can use RAM. The difference is that the kernel is relieved from the requirement to guarantee integrity on disk, and to write everything to disk ultimately at all if it doesn't otherwise need to. And that's what makes things a bit faster, and reduces general IO load and wakeups.
Beyond that it's also kind of nice that this way stuff from /tmp is allocated from a different pool as the rest of the OS so that we can easily apply different limits, but that's just a nice side benefit.
I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future...
Lennart
Am 01.06.2012 18:21, schrieb Lennart Poettering:
I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future...
no, you are missing the balance between POSSIBLE benefits and side-effects and lot of work from admins and pakcages
* it is a valid workload that a application creates a 10 GB tempfile * ok, you say: use /var/tmp * well, i say: my whole rootfs is only 4 GB and 2 Gb are used
so waht do we do now?
i known my workload and created a 30 GB /tmp my rootfs is large enough /var/log and /var/cache are own partitions
the 10 GB temp-file will not be stored in /tmp where is enough storage because yoz enforce pakcages to "fix" apllications not use your holy /tmp for large things
the 10 GB temp-file does not fit in rootfs aka /var/tmp the 10 GB temp-file does not fit in the memory
did you EVER think about real workloads?
On 06/01/2012 12:21 PM, Lennart Poettering wrote:
I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future...
Lennart
I understand how memory management works...which is why this seems like a terrible idea.
Can you provide numbers that show that there is a speed increase with this scheme which offsets the amount of change required to do this? I haven't seen anything other than "its faster".
This is change is troublesome for multiple reasons: * It switches the semantics of what /tmp is. Its now apparently for small and short-lived files. Where small and short-lived are defined based on the RAM usage at the time a file is created. Hooray for heisenbugs! * everything that did use /tmp now should use /var/tmp which means patching a ton of programs and hoping that third party applications do the same thing. So the "problem" this fixes with /tmp now exists in /var/tmp. * there are no numbers which back up the purported benefits * file data gets moved out of RAM (in this case, to swap) not when it is convenient for the kernel at a potentially idle time but when the kernel is experiencing memory pressure. * changing the amount of space available in /tmp means screwing with swap files
How is this change a win?
Brian Wheeler wrote:
How is this change a win?
Unfortunately, due to Lennart's ignorance (we're all ignorant of something), he will consider your e-mail "flame-bait" and not reply.
Not a single person who has claimed a performance or semantic win for this /tmp move has replied when asked for proof.
If someone would take the time to put "Implement contingency plan for /tmp Feature" on a FESCo agenda and get the ball rolling you might get something going. Right now these e-mail chains are doing precisely dick.
On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
Not a single person who has claimed a performance or semantic win for this /tmp move has replied when asked for proof.
$ time dd if=/dev/zero of=/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 4.95536 s, 2.2 GB/s dd if=/dev/zero of=/tmp/file bs=1M count=10240 0.00s user 3.44s system 69% cpu 4.956 total
No visual shanges in system behavior.
$ time dd if=/dev/zero of=/var/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 59.2188 s, 181 MB/s dd if=/dev/zero of=/var/tmp/file bs=1M count=10240 0.00s user 54.26s system 91% cpu 59.239 total
SSD disk. System becomes unresponsive for a couple of tens of seconds.
$ time dd if=/dev/zero of=$HOME/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 75.1548 s, 143 MB/s dd if=/dev/zero of=$HOME/file bs=1M count=10240 0.01s user 71.30s system 94% cpu 1:15.16 total
SATA disk. System becomes less responsive for a couple of seconds.
Does that counts as a proof? ext4 on /var and /home.
On Fri, Jun 01, 2012 at 11:00:57PM +0400, Alexey I. Froloff wrote:
On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
Not a single person who has claimed a performance or semantic win for this /tmp move has replied when asked for proof.
$ time dd if=/dev/zero of=/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 4.95536 s, 2.2 GB/s dd if=/dev/zero of=/tmp/file bs=1M count=10240 0.00s user 3.44s system 69% cpu 4.956 total
No visual shanges in system behavior.
I assume that your /tmp is on tmpfs; on all of *my* computers this command would fail because the tmpfs would be too limited to store a 10GB file.
$ time dd if=/dev/zero of=/var/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 59.2188 s, 181 MB/s dd if=/dev/zero of=/var/tmp/file bs=1M count=10240 0.00s user 54.26s system 91% cpu 59.239 total
SSD disk. System becomes unresponsive for a couple of tens of seconds.
No problem here. The machine isn't being unresponsive.
$ time dd if=/dev/zero of=$HOME/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 75.1548 s, 143 MB/s dd if=/dev/zero of=$HOME/file bs=1M count=10240 0.01s user 71.30s system 94% cpu 1:15.16 total
SATA disk. System becomes less responsive for a couple of seconds.
I can't reproduce this. System works fine for me.
Rich.
Alexey I. Froloff wrote:
$ time dd [snip] Does that counts as a proof?
It, in fact, provides proof that this feature is searching for a problem. Which applications require gigabytes per second throughput out of /tmp?
(and your numbers for tmpfs would equal ext4 once you started swapping)
On Fri, Jun 01, 2012 at 02:20:02PM -0500, Michael Cronenworth wrote:
It, in fact, provides proof that this feature is searching for a problem. Which applications require gigabytes per second throughput out of /tmp?
sort(1) and maybe mock(1) ;-)
(and your numbers for tmpfs would equal ext4 once you started swapping)
No. Tried with 2G RAM, 8G swap, 6G tmpfs and 5G file. Stupid dd test was 2-3 times faster on tmpfs that ext4.
Am 04.06.2012 12:50, schrieb Alexey I. Froloff:
On Fri, Jun 01, 2012 at 02:20:02PM -0500, Michael Cronenworth wrote:
It, in fact, provides proof that this feature is searching for a problem. Which applications require gigabytes per second throughput out of /tmp?
sort(1) and maybe mock(1) ;-)
(and your numbers for tmpfs would equal ext4 once you started swapping)
No. Tried with 2G RAM, 8G swap, 6G tmpfs and 5G file. Stupid dd test was 2-3 times faster on tmpfs that ext4.
but the stupid dd-test does not reflect reality
for most workloads /tmp is not touched most of the time in any way - keep in mind that applications needs to be changed to usr /var/tmp if they expect really large temp-files compare the real benefit with the complete work and bugreports for forgotten packages trying to store a iso-image and such things on /tmp
the benefit for the normal workload has to be compared with the overall work for a feature and not only some generic tests
On 06/01/2012 03:00 PM, Alexey I. Froloff wrote:
On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
Not a single person who has claimed a performance or semantic win for this /tmp move has replied when asked for proof.
$ time dd if=/dev/zero of=/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 4.95536 s, 2.2 GB/s dd if=/dev/zero of=/tmp/file bs=1M count=10240 0.00s user 3.44s system 69% cpu 4.956 total
No visual shanges in system behavior.
How much memory do you have to be able to write 11GB to /tmp ???
$ time dd if=/dev/zero of=/var/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 59.2188 s, 181 MB/s dd if=/dev/zero of=/var/tmp/file bs=1M count=10240 0.00s user 54.26s system 91% cpu 59.239 total
SSD disk. System becomes unresponsive for a couple of tens of seconds.
$ time dd if=/dev/zero of=$HOME/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 75.1548 s, 143 MB/s dd if=/dev/zero of=$HOME/file bs=1M count=10240 0.01s user 71.30s system 94% cpu 1:15.16 total
SATA disk. System becomes less responsive for a couple of seconds.
Does that counts as a proof? ext4 on /var and /home.
On Fri, 2012-06-01 at 23:00 +0400, Alexey I. Froloff wrote:
On Fri, Jun 01, 2012 at 01:50:55PM -0500, Michael Cronenworth wrote:
Not a single person who has claimed a performance or semantic win for this /tmp move has replied when asked for proof.
$ time dd if=/dev/zero of=/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 4.95536 s, 2.2 GB/s dd if=/dev/zero of=/tmp/file bs=1M count=10240 0.00s user 3.44s system 69% cpu 4.956 total
No visual shanges in system behavior.
Can you please repeat this on a Virtual Machine with 1GiB of RAM and 1GiB of swap ?
Simo.
On Fri, Jun 1, 2012 at 2:50 PM, Michael Cronenworth mike@cchtml.com wrote:
Not a single person who has claimed a performance or semantic win for this /tmp move has replied when asked for proof.
I haven't bothered because I have no clue what you'll accept and I fully accept you to move the goalposts.
For example, I build firefox in /tmp which is on tmpfs for me because on mostly finished trees the make is about 40% faster than with it on the disk. (51 seconds vs 72 seconds.
On Fri, Jun 01, 2012 at 03:22:32PM -0400, Gregory Maxwell wrote:
On Fri, Jun 1, 2012 at 2:50 PM, Michael Cronenworth mike@cchtml.com wrote:
Not a single person who has claimed a performance or semantic win for this /tmp move has replied when asked for proof.
I haven't bothered because I have no clue what you'll accept and I fully accept you to move the goalposts.
For example, I build firefox in /tmp which is on tmpfs for me because on mostly finished trees the make is about 40% faster than with it on the disk. (51 seconds vs 72 seconds.
Can you not use a custom tmpfs (eg. mounted on /var/lib/mock) for your specialist need?
Rich.
Gregory Maxwell wrote:
I haven't bothered because I have no clue what you'll accept and I fully accept you to move the goalposts.
Fedora application usage.
For example, I build firefox in /tmp which is on tmpfs for me because on mostly finished trees the make is about 40% faster than with it on the disk. (51 seconds vs 72 seconds.
This would not qualify, IMHO. We could argue all day about weird, unique use cases we all have for /tmp, but I think it would be saner to discuss usage by Fedora applications.
P.S. You should Google "ramdisk" or follow Richard's suggestion for /var/lib/mock.
On Fri, 2012-06-01 at 13:50 -0500, Michael Cronenworth wrote:
Brian Wheeler wrote:
How is this change a win?
Unfortunately, due to Lennart's ignorance (we're all ignorant of something), he will consider your e-mail "flame-bait" and not reply.
Its not his ignorance - he's on vacation for the next two weeks...
Am 04.06.2012 15:36, schrieb Matthias Clasen:
On Fri, 2012-06-01 at 13:50 -0500, Michael Cronenworth wrote:
Brian Wheeler wrote:
How is this change a win?
Unfortunately, due to Lennart's ignorance (we're all ignorant of something), he will consider your e-mail "flame-bait" and not reply.
Its not his ignorance - he's on vacation for the next two weeks...
that is not the point
his features are usually taken with no interest was the userbase thinks - in case of /tmp on tmpfs i see no prove what should be really faster, how much faster and if this is measurable in typical workloads
* most users will not notice any improvement * many users explained why it is a bad idea to change defaults * users who think it is good for their worksload are donig it since years
so why are features causing global changes to the distribution approved without careful condiseration and repeatly ignoring the userbase?
you can not say 10.000 users which are not crying out loud are automatically pro
Matthias Clasen wrote:
Its not his ignorance - he's on vacation for the next two weeks...
Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was an hour after that as a pretty good indication Lennart was not going to reply. Unless the timing was coincidental of him packing his bags, I'm still sticking with my post.
On Mon, Jun 04, 2012 at 08:44:38AM -0500, Michael Cronenworth wrote:
Matthias Clasen wrote:
Its not his ignorance - he's on vacation for the next two weeks...
Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was an hour after that as a pretty good indication Lennart was not going to reply. Unless the timing was coincidental of him packing his bags, I'm still sticking with my post.
Expecting and more or less demanding a reply after calling someone ignorant... not nice behaviour.
On Tue, Jun 5, 2012 at 12:28 AM, Olav Vitters olav@vitters.nl wrote:
On Mon, Jun 04, 2012 at 08:44:38AM -0500, Michael Cronenworth wrote:
Matthias Clasen wrote:
Its not his ignorance - he's on vacation for the next two weeks...
Brian replied to Lennart 7 minutes after Lennart's e-mail and mine was an hour after that as a pretty good indication Lennart was not going to reply. Unless the timing was coincidental of him packing his bags, I'm still sticking with my post.
Expecting and more or less demanding a reply after calling someone ignorant... not nice behaviour.
-- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
If Puttering really went on vacation after dropping a bombshell like that, well, I'm thinking he should recuse himself.
Yeah. I'm getting personal here. Lennart has put a lot of edits into Fedora that are all about copying a design philosophy that has been disasterous where it has been used. (Or perhaps getting the Fedora community to do the grunt work on his Master's thesis on things that shouldn't be done in an OS?) Edits that will have to be rolled back if Fedora is to survive as the testbed for an enterprise class OS. Very costly edits.
Edits that have been eating my sack time, which is why I've been taking it personal.
But, as has been danced around in this thread several times already, allowing /tmp to consume half of a system's putative RAM is really, really perverse. (Unless you have stock in a company that sells RAM and CPUs with >32 bit addressing.) No, you can declaim how the system will auto-swap the RAM and "adjust things for you", but that is adding to the cycles the CPUs have to waste doing things that are just plain unnecessary.
tmpfs is there precisely because /tmp is not fast enough for certain applications. Those applications should know who they are. Leave it like that.
-- Joel Rees
On Thu, 21.06.12 00:01, Joel Rees (joel.rees@gmail.com) wrote:
If Puttering really went on vacation after dropping a bombshell like
My name is Poettering, not Puttering.
community to do the grunt work on his Master's thesis on things that
My master's thesis? Nah, no thanks, already got a good old german Diplom, no interest in a Master. (The Bologna process is evil anyway!)
Please be more careful with the facts when insulting somebody, thank you!
Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/12 19:42, Brian Wheeler wrote:
On 06/01/2012 12:21 PM, Lennart Poettering wrote:
I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future...
Lennart
I understand how memory management works...which is why this seems like a terrible idea.
Can you provide numbers that show that there is a speed increase with this scheme which offsets the amount of change required to do this? I haven't seen anything other than "its faster".
This is change is troublesome for multiple reasons: * It switches the semantics of what /tmp is. Its now apparently for small and short-lived files. Where small and short-lived are defined based on the RAM usage at the time a file is created. Hooray for heisenbugs! * everything that did use /tmp now should use /var/tmp which means patching a ton of programs and hoping that third party applications do the same thing. So the "problem" this fixes with /tmp now exists in /var/tmp. * there are no numbers which back up the purported benefits * file data gets moved out of RAM (in this case, to swap) not when it is convenient for the kernel at a potentially idle time but when the kernel is experiencing memory pressure. * changing the amount of space available in /tmp means screwing with swap files
How is this change a win?
I sense a long term strategy ...
a) Move /tmp to tmpfs b) all programs using /tmp uses /var/tmp c) all failing programs enforces $TMPDIR to be set to /var/tmp d) Somebody discovers that /tmp is no longer in use - and propose to remove /tmp all in all
But we're just at the beginning...
Having that said ... I really see some benefits of /tmp on tmpfs, but for large workloads which depends on /tmp or $TMPDIR it will be a pain, no matter what, IMO. And it strikes me as interesting that Solaris have been doing a similar tmpfs approach for years; yet still the thumb-rule seems to be "get rid of that ram-fs-stuff and put /tmp on a real drive". And I wonder why........
A couple of times (several years ago now), I've experienced /tmp being filled up with junk - and at that time /tmp was a part of /. And that caused even more fun challenges. So I started deploying /tmp on a separate LVM logical volume, with a restricted space. Since that time, all systems have been running quite stable - despite /tmp getting filled up from time to time. But that's usually not a problem, as in worst case that misbehaving program just dies.
But I'm really curious to see what happens if this happens on a tmpfs based /tmp. If you have 4GB RAM server and a 4GB swap ... and then a program hits the system creating 8-9GB of trash in /tmp ... how will that impact the performance and responsiveness of the overall system? How will applications reading data from these memory pages being swapped out behave (in a performance, point of view) Will OOM killer at some point kick in? And if OOM killer starts, I'm curious which processes it will pick to kill ... I imagine this to be particular funny if you're running something RAM intensive, like something Java based (JBoss anyone?).
I've been seeing a tendency for quite some that these new "features" in Fedora only benefits a smaller restricted set of laptop (and to some degree workstation) configurations ... while Fedora is the base for something far bigger and real servers might have completely different needs. But as they say ... ignorance is a bliss ...
Yes, /tmp on tmpfs might make a lot of sense on many laptops/netbooks/ultrabooks, SSD based systems and other places where I/O load and energy consumption is crucial - and especially if you have plenty of RAM. But (spinning) disk space is still fairly cheap, and /tmp on a real disk behaves in a predictable manner - even with misbehaving programs. And RAM is far more expensive per GB than spinning disks.
I'm sorry to say, I still haven't really seen any good arguments why this move is a clever idea on *all* installations. Some installations, yes, but default for not all.
kind regards,
David Sommerseth
On Thu, Jul 12, 2012 at 6:43 PM, David Sommerseth davids@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/12 19:42, Brian Wheeler wrote:
On 06/01/2012 12:21 PM, Lennart Poettering wrote:
I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works and the assumption that having an explicit size limit on /tmp was a bad thing, even though it actually is a good thing... In fact, we need much stronger limits than what tmpfs currently provides: per-user limits on the usage of /tmp. But that's something for the future...
Lennart
I understand how memory management works...which is why this seems like a terrible idea.
Can you provide numbers that show that there is a speed increase with this scheme which offsets the amount of change required to do this? I haven't seen anything other than "its faster".
This is change is troublesome for multiple reasons: * It switches the semantics of what /tmp is. Its now apparently for small and short-lived files. Where small and short-lived are defined based on the RAM usage at the time a file is created. Hooray for heisenbugs! * everything that did use /tmp now should use /var/tmp which means patching a ton of programs and hoping that third party applications do the same thing. So the "problem" this fixes with /tmp now exists in /var/tmp. * there are no numbers which back up the purported benefits * file data gets moved out of RAM (in this case, to swap) not when it is convenient for the kernel at a potentially idle time but when the kernel is experiencing memory pressure. * changing the amount of space available in /tmp means screwing with swap files
How is this change a win?
I sense a long term strategy ...
a) Move /tmp to tmpfs b) all programs using /tmp uses /var/tmp c) all failing programs enforces $TMPDIR to be set to /var/tmp d) Somebody discovers that /tmp is no longer in use - and propose to remove /tmp all in all
But we're just at the beginning...
Having that said ... I really see some benefits of /tmp on tmpfs, but for large workloads which depends on /tmp or $TMPDIR it will be a pain, no matter what, IMO. And it strikes me as interesting that Solaris have been doing a similar tmpfs approach for years; yet still the thumb-rule seems to be "get rid of that ram-fs-stuff and put /tmp on a real drive". And I wonder why........
A couple of times (several years ago now), I've experienced /tmp being filled up with junk - and at that time /tmp was a part of /. And that caused even more fun challenges. So I started deploying /tmp on a separate LVM logical volume, with a restricted space. Since that time, all systems have been running quite stable - despite /tmp getting filled up from time to time. But that's usually not a problem, as in worst case that misbehaving program just dies.
But I'm really curious to see what happens if this happens on a tmpfs based /tmp. If you have 4GB RAM server and a 4GB swap ... and then a program hits the system creating 8-9GB of trash in /tmp ... how will that impact the performance and responsiveness of the overall system? How will applications reading data from these memory pages being swapped out behave (in a performance, point of view) Will OOM killer at some point kick in? And if OOM killer starts, I'm curious which processes it will pick to kill ... I imagine this to be particular funny if you're running something RAM intensive, like something Java based (JBoss anyone?).
Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time.
Am 12.07.2012 21:54, schrieb Harald Hoyer:
Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time.
is it limited to half the RAM or 2 GB? on my machine half the RAM is 8 GB
what about a application storing 4 GB in /tmp no longer possible
however, it is still bullshit AS DEFAULT do not touch users RAM for temp crap
if the application thinks it is useful to buffer something in the RAm it can do this since many years and THIS is the memory you can swap out if needed
why do some people all the time introduce braindead changes for the sake of the change? leave the system as it is if it works fine and search a hobby beside IT if you are bored!
On 07/12/2012 09:54 PM, Harald Hoyer wrote:
Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time.
As I have already pointed out some time ago, isn't a bizarre situation that as an application developer I can either use malloc() and store things up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store things up to RAM/2 (lets' say 4/2=2GB)?
Once upon a time you used to use files to go *beyond* RAM limits.
And the answer to this objection is....? move to /var/tmp. So patch everything (and good luck with closed source stuff).
Wouldn't have been more reasonable to create a /ramtmp and patch the applications? (this would have just been "patched for speed", not "patched for correctness" as the sort case). Hey, wait, we already have /dev/shm. So we just had to patch the applications (if anyone cares).
On 07/13/2012 09:14 AM, Roberto Ragusa wrote:
On 07/12/2012 09:54 PM, Harald Hoyer wrote:
Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time.
As I have already pointed out some time ago, isn't a bizarre situation that as an application developer I can either use malloc() and store things up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store things up to RAM/2 (lets' say 4/2=2GB)?
Once upon a time you used to use files to go *beyond* RAM limits.
And the answer to this objection is....? move to /var/tmp. So patch everything (and good luck with closed source stuff).
An application (closed source or not) that plans to store non-trivial amounts of data somewhere should have a mechanism/config option to let the user specify where to store that data. Simply hoping that you can dump X gigabytes of data in some hard-coded place is not a good idea.
Wouldn't have been more reasonable to create a /ramtmp and patch the applications? (this would have just been "patched for speed", not "patched for correctness" as the sort case). Hey, wait, we already have /dev/shm. So we just had to patch the applications (if anyone cares).
That way *every* application would have to be patched. Using /var/tmp is only required for a small number of apps that actually have more specific needs regarding the data they intend to put there. Indeed in many cases it might be better for an application to actually manage the "temporary-ness" of the file(s) in question themselves and store/manage them in /var/lib/<app> instead.
Regards, Dennis
On 07/13/2012 10:14 AM, Dennis Jacobfeuerborn wrote:
On 07/13/2012 09:14 AM, Roberto Ragusa wrote:
On 07/12/2012 09:54 PM, Harald Hoyer wrote:
Again.. tmpfs is restricted to half the RAM size by default. You can't store 8-9GB of trash.. only 2GB, which might land on swap over time.
As I have already pointed out some time ago, isn't a bizarre situation that as an application developer I can either use malloc() and store things up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store things up to RAM/2 (lets' say 4/2=2GB)?
Once upon a time you used to use files to go *beyond* RAM limits.
And the answer to this objection is....? move to /var/tmp. So patch everything (and good luck with closed source stuff).
An application (closed source or not) that plans to store non-trivial amounts of data somewhere should have a mechanism/config option to let the user specify where to store that data. Simply hoping that you can dump X gigabytes of data in some hard-coded place is not a good idea.
Sure, its not a good idea, but its been done for decades...successfully.
Wouldn't have been more reasonable to create a /ramtmp and patch the applications? (this would have just been "patched for speed", not "patched for correctness" as the sort case). Hey, wait, we already have /dev/shm. So we just had to patch the applications (if anyone cares).
That way *every* application would have to be patched. Using /var/tmp is only required for a small number of apps that actually have more specific needs regarding the data they intend to put there.
And right here is the problem. The "more specific need" is now based on size of the data relative to the amount of memory in the machine. That's just messed up.
Does anaconda on F18 put /home and / on different volumes? I did a rawhide install using the F17 and all defaults and they're combined. Under this scenario I have sizeof(rootfs) - 5G of disk I can potentially use for /tmp. Under the tmpfs scheme I have 1G (this is a 2G VM) . The answer is, of course, to use /var/tmp -- which only moved the "problem" and didn't do squat except to generate a bunch of patches which amounted to s|/tmp|/var/tmp|g
To make this a default was a dumb decision which has never been adequately justified. I did finally see some performance numbers for a software build, but that isn't the general case and I can't believe the benefits touted even impact the general case, especially given the size limitations of /tmp.
On Fri, Jun 01, 2012 at 06:21:28PM +0200, Lennart Poettering wrote:
ext3 otoh means must be on disk in the end, [...]
This is plainly not true. If you create a file and immediate delete it, ext3 won't write the data to disk (metadata is slightly different, but in any case very small).
What are the numbers to support your argument that having a hard limit on the size of /tmp is a benefit, in terms of performance or anything else?
I think most of the noise in this flame thread is due to a misunderstanding how modern memory management works [...]
I don't think so.
Rich.
On 06/01/2012 11:05 AM, Gregory Maxwell wrote:
On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno greno@verizon.net wrote:
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. That's crazy.
Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap.
Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp.
Plus the purported benefit from this is causing less write cycles on SSD. (See Wiki page)
That may have been a benefit a few years ago but newer SSD's will gain almost nothing from this because of the enormous number of write cycles they handle.
This "feature" may have some benefits but I think they are infinitesimally small.
.
On Fri, Jun 1, 2012 at 11:27 AM, Gerry Reno greno@verizon.net wrote:
Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp. Plus the purported benefit from this is causing less write cycles on SSD. (See Wiki page) That may have been a benefit a few years ago but newer SSD's will gain almost nothing from this because of the enormous number of write cycles they handle.
You're not understanding the word "allocate" in the same way it actually behaves. It does not reserve memory. The default maximum size (think of it as a quota) of a tmpfs mount is half whatever amount of actual ram you have. You can expand or shrink a tmpfs mount using the size= mount option.
Memory is not actually used until things are stored there, and if the result is memory pressure the kernel will intelligently page out the least used pages. (e.g. tmp files that haven't been accessed in a long time, or inactive application memory instead of an actively accessed file on tmp), per the normal vm policy.
Because that disk activity only happens when the kernel decides that it wants the memory for something else it doesn't happen at all in a great many cases especially for short lived files.
This "feature" may have some benefits but I think they are infinitesimally small.
The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed.
On 06/01/2012 11:35 AM, Gregory Maxwell wrote:
Because that disk activity only happens when the kernel decides that it wants the memory for something else it doesn't happen at all in a great many cases especially for short lived files.
...
The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed.
Um, aren't both of those benefits the same as one would get when using ext4's delayed allocation?
Does anyone have any actual numbers for the performance increase? I've never seen any numbers, but I've heard the claim repeatedly.
Once upon a time, Brian Wheeler bdwheele@indiana.edu said:
Um, aren't both of those benefits the same as one would get when using ext4's delayed allocation?
Delayed allocation still has to flush metadata changes to storage regularly as well as possibly read metadata from storage to find available inodes, while tmpfs only has to touch storage under pressure from high RAM utilization.
Am 01.06.2012 17:35, schrieb Gregory Maxwell:
The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed
pff and this is a generic worklaod for MAJORITY of the user-base? no? hmm wait a minute...
if it is not why should DEFAULTS are changed and a unknown amount of packages broken/fixed/patched to no longer touch /tmp and blow all temorary stuff to /var/tmp
the MINORITY can add the line in /etc/fstab since ten years and be happy as all the time before - the rest does not need it or is even hurted by the change
what currently happens is that based on a exotic workload majority of users and packagers are forced to act in a way few people thought "may be nice"
On 06/01/2012 11:35 AM, Gregory Maxwell wrote:
On Fri, Jun 1, 2012 at 11:27 AM, Gerry Reno greno@verizon.net wrote:
This "feature" may have some benefits but I think they are infinitesimally small.
The feature may be adopted/promoted on the basis of SSD writecycle preservation, but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— which is the reason that many people have been using tmpfs for /tmp on many systems for much longer than SSDs have existed.
Well, I don't have any workloads that are doing high-speed create/remove of file in /tmp.
And I don't think most people have any of those types of workloads either.
Wouldn't it make sense that people with those types of workloads could enable /tmp on tmpfs?
Rather than making it the default for everyone.
.
Am 01.06.2012 17:44, schrieb Gerry Reno:
Well, I don't have any workloads that are doing high-speed create/remove of file in /tmp. And I don't think most people have any of those types of workloads either.
Wouldn't it make sense that people with those types of workloads could enable /tmp on tmpfs? Rather than making it the default for everyone.
they can since many years, now all others have to learn how fix back the setup for their workloads
echo "tmpfs /tmp tmpfs defaults,noatime,nodiratime,noexec,size=500m" >> /etc/fstab
changes in fedora are often not for the userbase they are often only for the sake of the change
On Fri, Jun 01, 2012 at 11:44:12AM -0400, Gerry Reno wrote:
Well, I don't have any workloads that are doing high-speed create/remove of file in /tmp.
And I don't think most people have any of those types of workloads either.
I do, but ext4 handles my workload marvelously. For high-speed create/remove, /tmp appears as though it were a tmpfs without any of the drawbacks. The details of performance probably depend on each individual workload, but it would be nice to see evidence that tmpfs is really a noticeable benefit for a variety of workloads.
Wouldn't it make sense that people with those types of workloads could enable /tmp on tmpfs?
Rather than making it the default for everyone.
That seems like a very reasonable approach, and if tmpfs turns out to be an obvious improvement for most users, then the default could be reconsidered in the future.
-- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
The feature may be adopted/promoted on the basis of SSD writecycle preservation,
I'm about to put in an SSD boot disk, so I care about this argument, but I'm still not using tmpfs, for my reasons stated previously.
but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed—
This conclusion is NOT TRUE for me. I've checked it. /tmp on ext3 on my system does NOT incur any disk I/O until long after the process using it has finished, if at all, as long as the files are small and transient.
And if they're neither small nor transient, RAM is the wrong place for them anyway.
Perhaps a better solution is to look at TRIM support for the I/O buffers, and see if they're writing to the disk after the file has been deleted? If they're doing the sane thing, there should be no disk I/O at all anyway, unless you really needed disk storage in the first place.
On Fri, Jun 1, 2012 at 12:27 PM, DJ Delorie dj@redhat.com wrote:
This conclusion is NOT TRUE for me. I've checked it. /tmp on ext3 on my system does NOT incur any disk I/O until long after the process using it has finished, if at all, as long as the files are small and transient.
Glad to see you've taken the all caps advice.
I'm not sure what you're measuring though, because the metadata absolutely does get written write away for me. For a more dramatic example touch a file then hit the power button a few seconds later.
And if they're neither small nor transient, RAM is the wrong place for them anyway.
If they really aren't transient then /tmp is the wrong place for them. But regardless, if ram isn't the IO optimal place for them then they won't remain in ram.
If they really aren't transient then /tmp is the wrong place for them.
I will categorically disagree with any argument of the "the user shouldn't be doing that" type. Software exists to serve the user, not the other way around.
Besides, I often don't realize that a file isn't transient until *after* it's in /tmp. Such is life :-P
On Fri, Jun 1, 2012 at 2:28 PM, DJ Delorie dj@redhat.com wrote:
If they really aren't transient then /tmp is the wrong place for them.
I will categorically disagree with any argument of the "the user shouldn't be doing that" type. Software exists to serve the user, not the other way around.
Your quoting removed the fact that I was responding a statement that ram was the "wrong place". I was simply extending the comment. If you're willing to say that ram is the wrong place for something then there is nothing user hostile to say tmp is too.
Tmp already gets ruthlessly script deleted. It's really not a good place to keep things you're planning on keeping for a long time, tmpfs or no.
Your quoting removed the fact that I was responding a statement that ram was the "wrong place". I was simply extending the comment. If you're willing to say that ram is the wrong place for something then there is nothing user hostile to say tmp is too.
"Wrong" in general has been used here as a generic excuse to "do what's best for the user, and they'd better like it because they're wrong if they don't do what we tell them".
IMHO *telling* the user how to manage /tmp is wrong, whichever side of the argument you're on. *Asking* them how to manage it is the right way. That was my point in that mail.
*I* want /tmp on disk. I still don't want someone else telling me I have to do it that way.
On Fri, 2012-06-01 at 14:46 -0400, DJ Delorie wrote:
IMHO *telling* the user how to manage /tmp is wrong, whichever side of the argument you're on. *Asking* them how to manage it is the right way. That was my point in that mail.
*I* want /tmp on disk. I still don't want someone else telling me I have to do it that way.
You are entirely free to configure it through /etc/fstab. But to say that 'the system' should ask 'the user' to make every major config choice for it is just untenable and absurd.
Yes, it's 'just' another checkbox in the installer. Feel free to join #anaconda and see how easy it is to keep track of the seventy zillion checkboxes (i.e. codepaths) we currently have in the installer when trying to redesign it in a way that makes any goddamn sense.
Philosophically: the whole _job_ of a distribution is to make choices for 'the user'. That's what we do. We look at the bewildering array of choices you can make in deploying a bunch of bits to a system in order to be able to actually use it, and make lots of those choices, so that people can go ahead and stick a disc in a drive and click a few buttons and get a working system, instead of spending three weeks researching what a tmpfs even _is_.
Let's make some logical extensions of your position. When I start installing Fedora, it should ask me whether I want to install grub, grub2, or lilo. Then ask me what framebuffer mode and console font I'd like to use. Then it should probably ask me whether to use udev or a static /dev tree. Then it could maybe ask what system initialization daemon it should use, systemd or upstart. Then ask whether we want to use dpkg or rpm, and access a different repository accordingly. Then we could get into the real meaty stuff, like do I want ash or bash. Do I want chronyd or ntpd.
It's just freaking absurd. Our job is to deploy a cohesive system - i.e. to make choices about basic system design. Not to create a giant choose-your-own-adventure interface to encapsulate all the possible options of system configuration policy.
I realize I'm arguing extremes here, and of course there's a happy medium somewhere between 'ask what the core limit should be' and 'one click installer'. There are _some_ choices that have to be left up to the user, and some that probably ought to be. But you seem to be arguing a) that one specific obscure and probably not-widely-understood item of distro configuration should be explicitly left up to the user at install time because 'everything is about choice!', and b) in general, all such things should be 'optional' (not in terms of 'you can go in and change it if you really care', which is fine, but in terms of 'you will be forcibly confronted with a decision'). My position is that this is insane, against the whole concept of what a distribution is, impossible to maintain and impossible to QA (and hence will inevitably lead to a very buggy product).
On Fri, 2012-06-01 at 11:56 -0700, Adam Williamson wrote:
On Fri, 2012-06-01 at 14:46 -0400, DJ Delorie wrote:
IMHO *telling* the user how to manage /tmp is wrong, whichever side of the argument you're on. *Asking* them how to manage it is the right way. That was my point in that mail.
*I* want /tmp on disk. I still don't want someone else telling me I have to do it that way.
You are entirely free to configure it through /etc/fstab. But to say that 'the system' should ask 'the user' to make every major config choice for it is just untenable and absurd.
Ok, say I have installed my new laptop and discover that the new /tmp arrangement is not good for me and I'd rather keep /tmp on disk, how do you go about that ? (No I do not have any un-partitioned space left, and using the root file system is fine by me)
Yes, it's 'just' another checkbox in the installer. Feel free to join #anaconda and see how easy it is to keep track of the seventy zillion checkboxes (i.e. codepaths) we currently have in the installer when trying to redesign it in a way that makes any goddamn sense.
I think the question here is can someone please point to a page with numbers that justify /tmp -> tmpfs be the default for the most common cases ? laptop / vm with limited RAM.
Philosophically: the whole _job_ of a distribution is to make choices for 'the user'. That's what we do. We look at the bewildering array of choices you can make in deploying a bunch of bits to a system in order to be able to actually use it, and make lots of those choices, so that people can go ahead and stick a disc in a drive and click a few buttons and get a working system, instead of spending three weeks researching what a tmpfs even _is_.
Absolutely correct, but there should be some good rationale when a change impact decades of use and habit and has the potential of breaking stuff.
Let's make some logical extensions of your position. When I start installing Fedora, it should ask me whether I want to install grub, grub2, or lilo. Then ask me what framebuffer mode and console font I'd like to use. Then it should probably ask me whether to use udev or a static /dev tree. Then it could maybe ask what system initialization daemon it should use, systemd or upstart. Then ask whether we want to use dpkg or rpm, and access a different repository accordingly. Then we could get into the real meaty stuff, like do I want ash or bash. Do I want chronyd or ntpd.
It's just freaking absurd. Our job is to deploy a cohesive system - i.e. to make choices about basic system design. Not to create a giant choose-your-own-adventure interface to encapsulate all the possible options of system configuration policy.
I totally agree here, we do not want to have this kind of choices, but we want *safe* defaults. The current /tmp setup is reasonably safe and fast enough for current needs, the transition to tmpfs has the potential of breaking a lot of stuff, so what is so good in tmpfs to warrant this big change ?
Where are the numbers ?
Simo.
On Fri, 2012-06-01 at 15:28 -0400, Simo Sorce wrote:
I think the question here is can someone please point to a page with numbers that justify /tmp -> tmpfs be the default for the most common cases ? laptop / vm with limited RAM.
No, that's the question in the main thread. This subthread is about me taking exception to DJ's general contention that choices about obscure bits of system policy like this should be explicitly forced on the user. I already clearly stated in my first reply to DJ that I'm not arguing in favour of either default setting. My point is simply that it is correct to pick a default and go with it, it's a bad design to ask the end user about this kind of thing during installation.
it's a bad design to ask the end user about this kind of thing during installation.
IIRC, I suggested a checkbox in the disk partitioning page, where we're already asking the user all sorts of questions about the filesystem layout and mount points (including putting /tmp on a separate partition), with defaults according to some logic. If the user chooses a standard install, they get the default.
On Fri, 2012-06-01 at 15:57 -0400, DJ Delorie wrote:
it's a bad design to ask the end user about this kind of thing during installation.
IIRC, I suggested a checkbox in the disk partitioning page, where we're already asking the user all sorts of questions about the filesystem layout and mount points (including putting /tmp on a separate partition), with defaults according to some logic. If the user chooses a standard install, they get the default.
We would very much like to have _fewer_ checkboxes (i.e.: choice) in the storage stage, not more. It's unmanageable as is.
On 06/02/2012 03:44 AM, Adam Williamson wrote:
On Fri, 2012-06-01 at 15:57 -0400, DJ Delorie wrote:
it's a bad design to ask the end user about this kind of thing during installation.
IIRC, I suggested a checkbox in the disk partitioning page, where we're already asking the user all sorts of questions about the filesystem layout and mount points (including putting /tmp on a separate partition), with defaults according to some logic. If the user chooses a standard install, they get the default.
We would very much like to have _fewer_ checkboxes (i.e.: choice) in the storage stage, not more. It's unmanageable as is.
This only works if defaults are 100& "fail-safe and reliable".
/tmp on tmpfs is not. It's usable as an option in some setups, but will cause mal-functions in others
=> It is not suitable as default.
On Wed, 2012-06-20 at 04:53 +0200, Ralf Corsepius wrote:
On 06/02/2012 03:44 AM, Adam Williamson wrote:
On Fri, 2012-06-01 at 15:57 -0400, DJ Delorie wrote:
it's a bad design to ask the end user about this kind of thing during installation.
IIRC, I suggested a checkbox in the disk partitioning page, where we're already asking the user all sorts of questions about the filesystem layout and mount points (including putting /tmp on a separate partition), with defaults according to some logic. If the user chooses a standard install, they get the default.
We would very much like to have _fewer_ checkboxes (i.e.: choice) in the storage stage, not more. It's unmanageable as is.
This only works if defaults are 100& "fail-safe and reliable".
/tmp on tmpfs is not. It's usable as an option in some setups, but will cause mal-functions in others
=> It is not suitable as default.
Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations...
Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations...
Yeah, I won't be adding any checkboxes to have people pick their /tmp style.
- Chris
On 06/20/2012 03:35 PM, Chris Lumens wrote:
Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations...
Yeah, I won't be adding any checkboxes to have people pick their /tmp style.
Then putting not putting /tmp on tmpfs is the only applicable default.
Am 20.06.2012 16:11, schrieb Ralf Corsepius:
On 06/20/2012 03:35 PM, Chris Lumens wrote:
Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations...
Yeah, I won't be adding any checkboxes to have people pick their /tmp style.
Then putting not putting /tmp on tmpfs is the only applicable default.
+100
a default has to be soemthing which is OK on EVERY setup
/tmp on tmpfs is clearly NOT OK for every setup this is a possible tuning depending on environment and workload
On 06/20/2012 10:16 AM, Reindl Harald wrote:
Am 20.06.2012 16:11, schrieb Ralf Corsepius:
On 06/20/2012 03:35 PM, Chris Lumens wrote:
Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations...
Yeah, I won't be adding any checkboxes to have people pick their /tmp style.
Then putting not putting /tmp on tmpfs is the only applicable default.
+100
a default has to be soemthing which is OK on EVERY setup
/tmp on tmpfs is clearly NOT OK for every setup this is a possible tuning depending on environment and workload
That's pretty specious. You're not going to see a machine that doesn't boot immediately after installation because /tmp is on tmpfs, so there's no reason you can't frame /not/ having it on tmpfs to be a possible tuning depending on environment and workload.
Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp .
Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp .
Given a choice between "works for everyone" and "works well for most, but fails in obscure ways for some", I'll choose the former.
I find it amusing that this argument is going for the "screw some of the users so others are happy" way, but the reboot-to-update argument is going the opposite, the "must always work for everyone no matter how painful" way.
On 06/20/2012 05:45 PM, Peter Jones wrote:
On 06/20/2012 10:16 AM, Reindl Harald wrote:
Am 20.06.2012 16:11, schrieb Ralf Corsepius:
On 06/20/2012 03:35 PM, Chris Lumens wrote:
Again: I'm perfectly happy if it is rejected as a feature. I don't really care either way. What I'd really hate to see is a checkbox in the installer so we are compelled to test both variations...
Yeah, I won't be adding any checkboxes to have people pick their /tmp style.
Then putting not putting /tmp on tmpfs is the only applicable default.
+100
a default has to be soemthing which is OK on EVERY setup
/tmp on tmpfs is clearly NOT OK for every setup this is a possible tuning depending on environment and workload
That's pretty specious. You're not going to see a machine that doesn't boot immediately after installation because /tmp is on tmpfs, so there's no reason you can't frame /not/ having it on tmpfs to be a possible tuning depending on environment and workload.
Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp .
Again: It is not reasonable, it's generally and basically unreliable and cause of instabilities and unreliablities. Whether it's close to being "usable" depends on a user's use-case. It might be usable on a 32GB RAM single-user laptop, but it's complete non-sense otherwise.
Just have your fellow co-worker dump an arbitrary 100GB file to /tmp and watch your system to start misbehaving.
Ralf
Am 20.06.2012 18:49, schrieb Ralf Corsepius:
Since you can look at it either way in that regard, it's completely reasonable to have the option that's best for most users as the default. As I see it, that's to enable tmpfs for /tmp .
Again: It is not reasonable, it's generally and basically unreliable and cause of instabilities and unreliablities. Whether it's close to being "usable" depends on a user's use-case. It might be usable on a 32GB RAM single-user laptop, but it's complete non-sense otherwise.
Just have your fellow co-worker dump an arbitrary 100GB file to /tmp and watch your system to start misbehaving.
i fear people here are getting more and more ignorant fro teh reality
what is the topic of this dicussion? someone (Lennart?) is thinking "tmpfs is cool"
to few people knowing REAL workloads and saying "it's ok for me"
i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp" this is the wrong perspective the right one is "the system must not crash if someone does"
if the system crashs the reason has tobe found and fixed and the reason for this will be /tmp on tmpfs there is nothing to think and calculate
it is simply a fact that drop a 100 or 200 Gb file into tmpfs will bring down each machine existing currently and in the next 5-10 years and making a deafult behave this way is terrible wrong, especially sell it as "improvement"
On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald h.reindl@thelounge.net wrote:
i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp" this is the wrong perspective the right one is "the system must not crash if someone does"
Good thing it doesn't.
Am 20.06.2012 19:18, schrieb Gregory Maxwell:
On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald h.reindl@thelounge.net wrote:
i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp" this is the wrong perspective the right one is "the system must not crash if someone does"
Good thing it doesn't
no it does not CRASH
but it starts crawling around because the system starts to swap and i have never seen any linux system not get unuseable for my taste while heavily swapping
_____________________________________
what is so difficulty to undersatnd:
a application has the choice:
* holding data in memory * writing data to a file
if the application thinks the data of the current workload is too big for memory why would it be a godd design for a operating system-default to say "does not bother me"?
So, how does this scenario work?
* The machine has 4G of RAM, * > 50% RAM is being used by actual software (firefox, eclipse, mail client, etc), so the other < 50% is pagecache * The machine has 4G of swap, none of which is active.
So then a user drops a 8.5G DVD image into /tmp.
On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root.
With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then? As I understand it, the program gets ENOSPC and there is NO free RAM: pagecache is full of that dvd data. swap is full of that dvd data. The rest of the RAM is program data that has nowhere to page out to. The system may not have crashed, but it is fubar: welcome to OOM killer territory
The answers of "don't do that, use /var/tmp" or "allocate more swap" are crap. The software isn't broken if it writes to /tmp, regardless of how many bugzilla entries get filed. Allocating more swap is a cop out because you've only pushed the problem to some file size that is larger, and you've tied up disk for a worst case scenario that may never come.
This introduces behavior that is highly dependent not only on the memory configuration of the machine, but the usage at the time the allocation happened, making this impossible to troubleshoot.
What are the benefits of this change again? Clearing /tmp at shutdown is interesting, but can be accomplished in other ways (although not as cleanly), and I have yet to see any hard numbers on I/O even though I have asked repeatedly.
Brian
On 06/20/2012 01:18 PM, Gregory Maxwell wrote:
On Wed, Jun 20, 2012 at 12:57 PM, Reindl Harald h.reindl@thelounge.net wrote:
i bet now someone is coming up wth "he must not dump a 100 Gb file to /tmp" this is the wrong perspective the right one is "the system must not crash if someone does"
Good thing it doesn't.
Once upon a time, Brian Wheeler bdwheele@indiana.edu said:
So, how does this scenario work?
- The machine has 4G of RAM,
client, etc), so the other < 50% is pagecache
- The machine has 4G of swap, none of which is active.
So then a user drops a 8.5G DVD image into /tmp.
On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root.
With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then?
2G gets written and then -ENOSPC. 2G gets pushed to swap.
The default for tmpfs mounts is an fs that is sized to RAM/2.
On 20/06/12 18:55, Chris Adams wrote:
2G gets written and then -ENOSPC. 2G gets pushed to swap.
The default for tmpfs mounts is an fs that is sized to RAM/2.
What is the scenario, where it's a KVM host and 3/4 physical ram is assigned to Guests?
On 06/20/2012 01:55 PM, Chris Adams wrote:
Once upon a time, Brian Wheeler bdwheele@indiana.edu said:
So, how does this scenario work?
- The machine has 4G of RAM,
client, etc), so the other < 50% is pagecache
- The machine has 4G of swap, none of which is active.
So then a user drops a 8.5G DVD image into /tmp.
On a traditional /tmp-on-disk if it filled up then you'd get an ENOSPC and user things can't write to disk, but the OS will be fine since 5% is reserved for root.
With tmpfs the pagecache will fill up and start to overflow to swap...until swap fills up. What happens then?
2G gets written and then -ENOSPC. 2G gets pushed to swap.
The default for tmpfs mounts is an fs that is sized to RAM/2.
So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram?
On 06/20/2012 08:06 PM, Brian Wheeler wrote:
So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram?
Let's say it in this way: on a 4GB machine if the application uses the RAM, it works until (4GB+swap), but if the application uses a /tmp file, it works until 2GB! ...so using /tmp means you have less space... (facepalm)
/tmp has always historically been a place where you dump large data. Disk size increases faster than RAM size. Switching disk storage to RAM storage by default is simply wrong.
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
it is simply a fact that drop a 100 or 200 Gb file into tmpfs will bring down each machine existing currently and in the next
No, it won't.
Also, the default partitioning scheme for the existing Fedora setup (with /tmp on /) also won't support dupming a 100G file in /tmp, because / doesn't end up with 100G free.
On Fri, 2012-06-01 at 12:47 -0700, Adam Williamson wrote:
On Fri, 2012-06-01 at 15:28 -0400, Simo Sorce wrote:
I think the question here is can someone please point to a page with numbers that justify /tmp -> tmpfs be the default for the most common cases ? laptop / vm with limited RAM.
No, that's the question in the main thread. This subthread is about me taking exception to DJ's general contention that choices about obscure bits of system policy like this should be explicitly forced on the user. I already clearly stated in my first reply to DJ that I'm not arguing in favour of either default setting. My point is simply that it is correct to pick a default and go with it, it's a bad design to ask the end user about this kind of thing during installation.
Sorry for hijacking the subthread, and I agree with you on this specific point.
Simo.
Once upon a time, Simo Sorce simo@redhat.com said:
Ok, say I have installed my new laptop and discover that the new /tmp arrangement is not good for me and I'd rather keep /tmp on disk, how do you go about that ? (No I do not have any un-partitioned space left, and using the root file system is fine by me)
RTF(Thread|Feature Page): systemctl mask tmp.mount
Am 01.06.2012 21:59, schrieb Chris Adams:
Once upon a time, Simo Sorce simo@redhat.com said:
Ok, say I have installed my new laptop and discover that the new /tmp arrangement is not good for me and I'd rather keep /tmp on disk, how do you go about that ? (No I do not have any un-partitioned space left, and using the root file system is fine by me)
RTF(Thread|Feature Page): systemctl mask tmp.mount
and that does also patch all applications back which starts using /var/tmp like "sort" as default for their temp-files?
once again - try to undrstand the COMPLETE impacts of a "feature" and not only pieces of it!
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
and that does also patch all applications back which starts using /var/tmp like "sort" as default for their temp-files?
I keep seeing sort as the primary example: how often are people sorting multi-gigabyte files? I've been running with either a separate partition for /tmp (1G-2G) or tmpfs for /tmp on servers and desktops for many years now (10+). I have never had sort fail. The only time I think I have had a problem was with some DVD-creator software some time back that copied the video files to /tmp (dumb #1) and then tried to create the ISO in /tmp and copy it out (dumb #2).
Am 01.06.2012 22:14, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
and that does also patch all applications back which starts using /var/tmp like "sort" as default for their temp-files?
I keep seeing sort as the primary example: how often are people sorting multi-gigabyte files? I've been running with either a separate partition for /tmp (1G-2G) or tmpfs for /tmp on servers and desktops for many years now (10+). I have never had sort fail. The only time I think I have had a problem was with some DVD-creator software some time back that copied the video files to /tmp (dumb #1) and then tried to create the ISO in /tmp and copy it out (dumb #2).
"sort" is only ONE application
you missed the point that packagers are enforced to change temp-dir of their applications to /var/tmp instead /tmp and so it does not help people only make their /etc/fstab-line for having /tmp on their dedicated tmp-partition/disk
their rootfs would still be get written full from all sort of applications - this changes mening any application using /tmp for large files in fedora has to be patched using /var/tmp
the same impact for ANY application which could create large temporary files (all sort of disk/iso images and so on)
P.S.: yes, i am sorting daily files with some GB with "sort" and cronjobs and i find it a little bit frustrating have to search for all it's usages and set "sort -T" because a useless feature with less benfit at all enforing packagers to change the standard location away from /tmp
On Fri, Jun 1, 2012 at 2:46 PM, DJ Delorie dj@redhat.com wrote:
*I* want /tmp on disk. I still don't want someone else telling me I have to do it that way.
You can still put tmp on a disk if you're the kind of advanced users who knows better enough to override the defaults.
But there does have to be a default. Fedora makes _many_ defaults which I find intolerable, coping with that and the breakage that comes from making my fedora install less standard is part of the costs of outsourcing my system administration to the fedora community— a cost that is usually well worth the benefit.
Many of the people responding to this have show a substantial misunderstanding of how it would work— e.g. the thought it would take up half their ram. Adding a prompt is not costless by any means, and I don't think it actually would achieve the goal of aligning the users needs with the system's behavior. It also doesn't scale to the millions of other decisions Fedora and its packages make on the user's behalf.
I think it's reasonable to demand that fedora continues to support a on-disk /tmp. But ... yea. You can't escape having defaults.
(My own complaints in Fedora e.g. about gnome3, for example— have been about how crappy the fedora experience is if you disable the gnome stuff, how many things break in mysterious ways, not that Fedora has a default I don't like)
On 06/01/2012 12:27 PM, DJ Delorie wrote:
The feature may be adopted/promoted on the basis of SSD writecycle preservation,
I'm about to put in an SSD boot disk, so I care about this argument, but I'm still not using tmpfs, for my reasons stated previously.
but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed—
This conclusion is NOT TRUE for me. I've checked it. /tmp on ext3 on my system does NOT incur any disk I/O until long after the process using it has finished, if at all, as long as the files are small and transient.
And if they're neither small nor transient, RAM is the wrong place for them anyway.
Perhaps a better solution is to look at TRIM support for the I/O buffers, and see if they're writing to the disk after the file has been deleted? If they're doing the sane thing, there should be no disk I/O at all anyway, unless you really needed disk storage in the first place.
You may be interested in this bug:
Once upon a time, Gerry Reno greno@verizon.net said:
Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp.
Not exactly. The default size limit for a tmpfs mount is half of RAM; the RAM is not allocated exclusively to the tmpfs. The files in a tmpfs mount live in the page cache and can be swapped out if needed.
On Fri, Jun 01, 2012 at 11:27:01AM -0400, Gerry Reno wrote:
Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp.
No-no-no! Default tmpfs size is half of physical RAM, that's all. That doesn't mean that is stays in RAM forever.
$ df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs 24G 1.9M 24G 1% /tmp $ free -m total used free shared buffers cached Mem: 15987 14653 1333 0 328 8402 -/+ buffers/cache: 5922 10065 Swap: 31251 55 31196
$ dd if=/dev/zero of=/tmp/file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 9.02507 s, 1.2 GB/s $ df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs 24G 11G 14G 42% /tmp $ free -m total used free shared buffers cached Mem: 15987 15892 95 0 13 10105 -/+ buffers/cache: 5773 10213 Swap: 31251 1464 29787
$ dd if=/dev/zero of=/tmp/enother-file bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 57.2924 s, 187 MB/s $ free -m total used free shared buffers cached Mem: 15987 15886 100 0 4 10251 -/+ buffers/cache: 5630 10357 Swap: 31251 10482 20769
$ rm -f /tmp/file /tmp/enother-file $ df -h /tmp Filesystem Size Used Avail Use% Mounted on tmpfs 24G 1.9M 24G 1% /tmp $ free -m total used free shared buffers cached Mem: 15987 5718 10268 0 5 146 -/+ buffers/cache: 5566 10420 Swap: 31251 108 31143
On Fri, Jun 1, 2012 at 7:05 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap.
I am _very_ concerned about large files in conjunction with tmpfs usage for general purpose /tmp by default. Especially on multi-user capable systems.
As a sysadmin...for a multi-seat configuration in a home network environment...do I really need to anticipate maximum large file tmp usage in calculating my swap partition size for my multi-user family? 8 gigs of ram... so to be safe I want to set up a swap of what...100 gigs to account for a potentially large /tmp of some maximum size?
Does swap backed tmpfs as /tmp currently jeopardize my system's health by making swap backup for in-memory processes compete with tmp files? If my users clog up /tmp will that reach a point where the kernel's oom process killer decided to start killing off running processes instead of throwing crap out of /tmp?
What happens when I have 2 users who are both downloading dvd iso sized images into /tmp as well as other things going on. Remind me... where does firefox by default cache in progress downloads for the "Open in" facility. Isn't it down in tmp? Do I really want things like firefox downloads paging out ram into swap and causing an overall system slowdown?
Without more information about how gracefully /tmp spill over into swap is handled, I'm inclined to say this really looks problematic as a default. And that's not even getting into the more complex issues of virtual machine configurations which typically run under heavier ram constraints than disk constraints.
-jef
On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta jspaleta@gmail.com wrote:
As a sysadmin...for a multi-seat configuration in a home network environment...do I really need to anticipate maximum large file tmp usage in calculating my swap partition size for my multi-user family? 8 gigs of ram... so to be safe I want to set up a swap of what...100 gigs to account for a potentially large /tmp of some maximum size?
This is an issue you have independent of tmpfs. How big does / need to be? (or if /tmp is on another volume due to the fragmentation mess it creates, how big does that volume need to be).
Does swap backed tmpfs as /tmp currently jeopardize my system's health by making swap backup for in-memory processes compete with tmp files? If my users clog up /tmp will that reach a point where the kernel's oom process killer decided to start killing off running processes instead of throwing crap out of /tmp?
Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem
If you set it high enough that you could fill swap and physical ram with tmpfs plus your workload, then yes, I believe you'd then see the OOM killer run. I've never had this happen because I've never set my tmpfs size larger than the available swap I had— so any OOM event always was due to applications using up too much core.
What happens when I have 2 users who are both downloading dvd iso sized images into /tmp as well as other things going on. Remind me... where does firefox by default cache in progress downloads for the "Open in" facility. Isn't it down in tmp? Do I really want things like firefox downloads paging out ram into swap and causing an overall system slowdown?
Yes, Firefox saves to /tmp by default.
Use of tmpfs will not not increase your disk IO. Under that workload I would expect your DVD data to end up in the swap volume, there is no adverse performance from this. At least in my experience/measurements writing out large data to tmpfs has performance equal to or better than writing out to regular filesystems.
Without more information about how gracefully /tmp spill over into swap is handled, I'm inclined to say this really looks problematic as a default. And that's not even getting into the more complex issues of virtual machine configurations which typically run under heavier ram constraints than disk constraints.
It really sounds to me that you're using a "ramdisk" as a mental model for tmpfs. That isn't what tmpfs is. Tmpfs is a filesystem backed by the kernel's buffer cache, and it can use whatever resources it likes to back it up. In practice small short lived things are purely in ram, while larger long lived data ends up on disk— but it does so at the kernel's leisure and in a manner which minimizes writes and latency critical operations.
Am 20.06.2012 19:41, schrieb Gregory Maxwell:
On Wed, Jun 20, 2012 at 1:25 PM, Jef Spaleta jspaleta@gmail.com wrote:
As a sysadmin...for a multi-seat configuration in a home network environment...do I really need to anticipate maximum large file tmp usage in calculating my swap partition size for my multi-user family? 8 gigs of ram... so to be safe I want to set up a swap of what...100 gigs to account for a potentially large /tmp of some maximum size?
This is an issue you have independent of tmpfs. How big does / need to be? (or if /tmp is on another volume due to the fragmentation mess it creates, how big does that volume need to be)
the huge difference between swapping and the size of swap or have /tmp on the normal file-system is that SWAP is dead space allocation and mostly useless on modern machines
a reserve on / for installed new applications, logfiles, /tmp and whatever will there be stored can be used in a mixed workload for EVERYTHING (data, tmp, logs...)
normally you know how much space you need for your target-setup and allocate around 2xneeded space for rootfs
your /tmp on tmpfs is only wasting space allocations and/or memory or your system simply crashs - you are also missing that if /tmp get's full and is on rootfs there are 5% reserved for root, so NOTHING happens to your system you can not repair easily
if you system starts to swap because a large file in tmpfs and swap is full your machine crashs, you have no way to do anything and in the worst c ase you will lose data
until now NOBODY was able to explain a real-world benefit for /tmp on tmpfs as argument for make it a default and i more and more refuse to undrsatnd how decisions are made in Fedora _____________________
this all feels like:
* one person has a idea late at night * the person makes a proposal * some people do not understand anything and says "why not" * the "feature" is approved
On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem
Okay that was what I was missing. Pegging the tmpfs to some percentage of available ram by default.
Follow up question.. is this value defined at install time or is it 50% of ram as seen at boot up? If I add or remove ram between boot ups, post-install does the tmpfs size automatically adjust to 50% of what is available at boot up?
-jef
On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta jspaleta@gmail.com wrote:
On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem
Okay that was what I was missing. Pegging the tmpfs to some percentage of available ram by default.
Follow up question.. is this value defined at install time or is it 50% of ram as seen at boot up? If I add or remove ram between boot ups, post-install does the tmpfs size automatically adjust to 50% of what is available at boot up?
It's 50% available at bootup by default (e.g. this is what you get when you provide no size option while mounting). I'm not sure what the systemd stuff is doing, I had the impression it was leaving this as a default. I don't know if this is a good thing or not.
On Wed, Jun 20, 2012 at 1:56 PM, Brian Wheeler bdwheele@indiana.edu wrote:
I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation.
With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure.
An anticdote is not data, but I've never personally experienced negative "thrashing" behavior from high tmpfs usage. I suppose thrashing only really happens when there is latency sensitive competition for the IO, and the kernel must be aggressive enough to avoid that.
When data is written to file systems normally the bulk will also remain in the buffer cache for a some span of time until there is memory pressure. The difference is how long it can remain (tmpfs has no mandatory flush) before being backed by disk, how much extra overhead there is from maintaining metadata (less for tmpfs than persistent file systems), and how much must be written right away to keep the fs consistent (none for tmpfs).
On Wed, Jun 20, 2012 at 2:06 PM, Brian Wheeler bdwheele@indiana.edu wrote:
So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram?
On systems where tmpfs is provisioned for /tmp in fstab you change a setting to get more space (provide size=fooG mount option). This is easier than adding more space to tmp when tmp is on root or some other file system.
I don't know how it will be set in systemd. Regardless of what systemd offers you could still toss in an option to remount it with more space after bootup.
Buying more ram to increase /tmp is silly of course. The default behavior is just a default it doesn't imply some kind of cosmic relationship between your tmpfs size and the amount of physical ram.
On 06/20/2012 02:16 PM, Gregory Maxwell wrote:
On Wed, Jun 20, 2012 at 1:54 PM, Jef Spaleta jspaleta@gmail.com wrote:
On Wed, Jun 20, 2012 at 9:41 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
Tmpfs volumes have a size set as a mount option. The default is half the physical ram (not physical ram plus swap). You can change the size with a remount. When its full, its full, like any other filesystem
Okay that was what I was missing. Pegging the tmpfs to some percentage of available ram by default.
Follow up question.. is this value defined at install time or is it 50% of ram as seen at boot up? If I add or remove ram between boot ups, post-install does the tmpfs size automatically adjust to 50% of what is available at boot up?
It's 50% available at bootup by default (e.g. this is what you get when you provide no size option while mounting). I'm not sure what the systemd stuff is doing, I had the impression it was leaving this as a default. I don't know if this is a good thing or not.
On Wed, Jun 20, 2012 at 1:56 PM, Brian Wheeler bdwheele@indiana.edu wrote:
I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation.
With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure.
An anticdote is not data, but I've never personally experienced negative "thrashing" behavior from high tmpfs usage. I suppose thrashing only really happens when there is latency sensitive competition for the IO, and the kernel must be aggressive enough to avoid that.
I was pretty sure that on the internet an anecdote == data. :)
When data is written to file systems normally the bulk will also remain in the buffer cache for a some span of time until there is memory pressure. The difference is how long it can remain (tmpfs has no mandatory flush) before being backed by disk, how much extra overhead there is from maintaining metadata (less for tmpfs than persistent file systems), and how much must be written right away to keep the fs consistent (none for tmpfs).
Perhaps, but if you've dumped a big file to /tmp on a real filesystem and then a minute or two later you startup something large, its probable that the kernel has flushed the data to disk and the pagecache has easily discardable pages to use for new data coming in. Under tmpfs the flush would be forced on page discard which would also be when things were being read into the system.
But in any case the I/O advantages have never been shown, despite multiple requests by myself and others.
On Wed, Jun 20, 2012 at 2:06 PM, Brian Wheeler bdwheele@indiana.edu wrote:
So the default is that I can use 2G in /tmp regardless of how much swap is present if the system memory size is 4G? So the only way to get more /tmp is to either mess with the max% or buy more ram?
On systems where tmpfs is provisioned for /tmp in fstab you change a setting to get more space (provide size=fooG mount option). This is easier than adding more space to tmp when tmp is on root or some other file system.
Well, yes and no. You also have to make sure you have enough backing swap or you're screwing yourself out of usable ram. The problem here is that the amount of /tmp by default is small by default so the tinkering with sizes is actually more likely to be required that it was before. And moving the requirement for "large files" (for some value of 'large' which depends on your memory configuration) to /var/tmp is just moving goalposts and not actually solving anything.
I don't know how it will be set in systemd. Regardless of what systemd offers you could still toss in an option to remount it with more space after bootup.
Buying more ram to increase /tmp is silly of course. The default behavior is just a default it doesn't imply some kind of cosmic relationship between your tmpfs size and the amount of physical ram.
Ah, but it is the default. Because of this, there are going to be dumbass howto sites out there saying that Fedora is broken because it requires you to buy more RAM to get increased swap space -- no matter how many times it is refuted here.
So I built a rawhide vm just now with 2G of ram and while it didn't move /tmp to tmpfs (maybe because it was an upgrade?), /run is in tmpfs and I did some experiments. Yes, it did limit me to 1G when writing a file which is fine -- except that as a user that is substantially smaller than the (disk size - 6G) size that one would have had on /tmp if it was on /. Which means that many users are going to have to mess with that setting in order to preserve their current workflow and/or solve goofy bugs. And they're going to have to do it in a way that doesn't screw up their machines because they set it higher than they have backing storage.
It also means that every byte living in /tmp is a byte that cannot be used for cache or programs (except for caching the stuff in /tmp), so we're less memory efficient than before and swap/ram sizes will have to be larger to do what was done before.
I know that we've been told that this is a done deal and that everyone should just get over it, but this is a feature that I think truly sucks for a lot of reasons and there hasn't been any _actual_ benefits that have been proven for it, just lots of hand waving and anecdotes about how it works.
<sarcasm> Maybe for F19 I'll submit a feature that requires all X apps have to use 8-bit color (oooh, and private colormaps) since its will make network rendering 3x faster and that what solaris used to do! Don't ask any questions, though, because you can't possibly understand and I know it just works for me. </sarcasm>
On Wed, Jun 20, 2012 at 4:57 PM, Brian Wheeler bdwheele@indiana.edu wrote:
But in any case the I/O advantages have never been shown, despite multiple requests by myself and others.
I posted some example numbers earlier in this thread. e.g. make on an already compiled firefox source was half the time on tmpfs compared to ext4— even though the workload was all hot cache. Also its easy to observe the write activity on tmp that happens even for short lived files and reducing write load on SSDs was one of the main arguments advanced for this change.
Well, yes and no. You also have to make sure you have enough backing swap or you're screwing yourself out of usable ram.
Yes, and the installer does this IIRC.
The problem here is that the amount of /tmp by default is small by default so the tinkering with sizes is actually more likely to be required that it was before.
Yes, this was why I said I didn't know if it was a good idea that systemd leaves the default alone or not. I don't run any of my systems that way.
If this change turns out to be problematic then I think this would be why.
<sarcasm> Maybe for F19 I'll submit a feature that requires all X apps have to use 8-bit color (oooh, and private colormaps) since its will make network rendering 3x faster and that what solaris used to do! Don't ask any questions, though, because you can't possibly understand and I know it just works for me.
You should just remove network transparency from the window system entirely. No one needs that and besides VNC/Spice is good enough for everyone!
</sarcasm>
On Wed, 2012-06-20 at 16:57 -0400, Brian Wheeler wrote:
I know that we've been told that this is a done deal and that everyone should just get over it, but this is a feature that I think truly sucks for a lot of reasons and there hasn't been any _actual_ benefits that have been proven for it, just lots of hand waving and anecdotes about how it works.
I'm not quite sure about this being a done deal. Anybody with strong arguments, which were not discussed on the FESCo meeting which ACKed the feature, can propose in the FESCo tracker to revert the decision.
On Thu, Jun 21, 2012 at 3:42 AM, Tomas Mraz tmraz@redhat.com wrote:
On Wed, 2012-06-20 at 16:57 -0400, Brian Wheeler wrote:
I know that we've been told that this is a done deal and that everyone should just get over it, but this is a feature that I think truly sucks for a lot of reasons and there hasn't been any _actual_ benefits that have been proven for it, just lots of hand waving and anecdotes about how it works.
I'm not quite sure about this being a done deal. Anybody with strong arguments, which were not discussed on the FESCo meeting which ACKed the feature, can propose in the FESCo tracker to revert the decision.
Additionally, it's been turned on in rawhide. If over the course of f18 development it becomes apparent that it's a major problem, and people make a strong case for this backed up by solid data, we can indeed revert and turn it off. Nothing is set in stone, but having the feature in rawhide is a good way to get an idea of how well it will work. Not perfect, but it's what rawhide is for.
-J
-- 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
On Thu, Jun 21, 2012 at 11:09 AM, DJ Delorie dj@redhat.com wrote:
Additionally, it's been turned on in rawhide.
Rawhide nightlies have been failing, though, so how do we test this?
. . .or anything else? Wait until it composes, and then test. Unfortunately.
-J
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, Jun 21, 2012 at 12:09:48 -0400, DJ Delorie dj@redhat.com wrote:
Additionally, it's been turned on in rawhide.
Rawhide nightlies have been failing, though, so how do we test this?
Run rawhide. You can do this by installing F17 and yum upgrading to rawhide. There is an issue with dracut not working with device-mapper-multipath installed. And there is a plymouth issue breaking mounting encrypted devices other than the root file system during boot. You can work around it manually fixing things up after every reboot, but it's a bit of a pain.
I had been testing /tmp on tmpfs, but turned it off because it was hiding /tmp where httpd had dumped a lot of core files which I was having trouble removing. There is probably some tricky way to bind mount / and get at that directory, but it was simpler to turn it off and reboot. I haven't turned it back on yet, because I was worried about httpd regularly filling /tmp up, but the problems seems to have stopped now.
Once upon a time, Bruno Wolff III bruno@wolff.to said:
I had been testing /tmp on tmpfs, but turned it off because it was hiding /tmp where httpd had dumped a lot of core files which I was having trouble removing. There is probably some tricky way to bind mount / and get at that
Yep, not even particularly tricky: mount -t bind / /mnt
On Thu, Jun 21, 2012 at 8:57 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Bruno Wolff III bruno@wolff.to said:
I had been testing /tmp on tmpfs, but turned it off because it was hiding /tmp where httpd had dumped a lot of core files which I was having trouble removing. There is probably some tricky way to bind mount / and get at that
Yep, not even particularly tricky: mount -t bind / /mnt
And if you don't like tmpfs on /tmp:
# systemctl mask tmp.mount
On 06/20/2012 01:41 PM, Gregory Maxwell wrote:
What happens when I have 2 users who are both downloading dvd iso sized images into /tmp as well as other things going on. Remind me... where does firefox by default cache in progress downloads for the "Open in" facility. Isn't it down in tmp? Do I really want things like firefox downloads paging out ram into swap and causing an overall system slowdown?
Yes, Firefox saves to /tmp by default.
Use of tmpfs will not not increase your disk IO. Under that workload I would expect your DVD data to end up in the swap volume, there is no adverse performance from this. At least in my experience/measurements writing out large data to tmpfs has performance equal to or better than writing out to regular filesystems.
I don't think its just a matter of quantity of I/O but _when_ the I/O happens. Instead of the pagecache getting flushed to disk when it is convenient for the system (presumably during a lull in I/O) the I/O is concentrated when there is a large change in the VM allocations -- which makes it very similar to a thrashing situation.
With a real filesystem behind it, the pages can just be discarded and reused when needed (providing they've been flushed) but in the case of tmpfs the pages only get flushed to swap when there is memory pressure.
Its not just writing out the data that needs to be measured, but any case where the threshold of memory-used-for-software crosses the tmpfs limit: loading libreoffice when the machine has more than 50% ram used by software is going to generate a bunch of writes as well as a ton of reads at the same time, rather than having them spaced out over time (potentially, at least)
On 05/31/2012 12:55 PM, Ralf Corsepius wrote:
On 05/31/2012 12:45 PM, Pádraig Brady wrote:
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
So I'll patch sort to default to /var/tmp rather than /tmp.
This would mean introducing a bug.
As far as I know:
/tmp is for large data with no expectation of reboot persistence /var/tmp is for large data with expectation of reboot persistence
tmpfs is for *small* data, so not a good choice for /tmp, it is certainly optimal for /var/run /var/lock and so on.
I suppose that an additional small-tmp (e.g. /tmpram) could be useful for some programs currently using tmp for very small files. But these programs should be patched to deviate from a traditional Unix convention. As small (and short lived) files are equally fast on tmpfs or disk based /tmp, the whole effort is probably pointless.
What would be a really good solution is the ability to specify very long timeouts for the VM write-back of a normal filesystem. Having /tmp dirty data in memory for 2 hours (and immune to normal sync commands) is the perfect approach. Have RAM? Use RAM. RAM pressure? Becomes a normal disk. (letting tmpfs swap is NOT the actually same thing, and I doubt you can set tmpfs much bigger than real RAM)
It is quite easy to come up with use-cases where a small /tmp will be a problem.
- any kind of temporary unpack/copy pattern, such as entering a tar.gz with mc, unpacking of installation files for (mostly proprietary) packages, ...
- vmware uses /tmp/ram0 (immediately unlinked) as guest RAM backstore
- I personally use /tmp for large files (including ISOs of DVD I want to burn and delete); maybe I'm the only one doing that...
- I just discovered that my /tmp is currently 3.2GiB. The majority of the space is for /tmp/kde-myusername/konsole*.tmp (700MiB+520MiB+364MiB+305MiB+117MiB+....), as I run konsole with unlimited scrollback buffer and some shells have easily been open for weeks.
If the feature is implemented and activated by default, I will just turn it off and live happy. It will just be one more thing in the growing list of defaults that should have never been changed. But be prepared to more than "one or two" future bugs of the kind "Oracle can't be installed", "my backup program fails", "the machine slows down to a crawl and only a reboot fixes it", ...
Best regards.
On 05/31/2012 08:57 AM, Roberto Ragusa wrote:
On 05/31/2012 12:55 PM, Ralf Corsepius wrote:
On 05/31/2012 12:45 PM, Pádraig Brady wrote:
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
So I'll patch sort to default to /var/tmp rather than /tmp.
This would mean introducing a bug.
As far as I know:
/tmp is for large data with no expectation of reboot persistence /var/tmp is for large data with expectation of reboot persistence
tmpfs is for *small* data, so not a good choice for /tmp, it is certainly optimal for /var/run /var/lock and so on.
I suppose that an additional small-tmp (e.g. /tmpram) could be useful for some programs currently using tmp for very small files. But these programs should be patched to deviate from a traditional Unix convention. As small (and short lived) files are equally fast on tmpfs or disk based /tmp, the whole effort is probably pointless.
What would be a really good solution is the ability to specify very long timeouts for the VM write-back of a normal filesystem. Having /tmp dirty data in memory for 2 hours (and immune to normal sync commands) is the perfect approach. Have RAM? Use RAM. RAM pressure? Becomes a normal disk. (letting tmpfs swap is NOT the actually same thing, and I doubt you can set tmpfs much bigger than real RAM)
It is quite easy to come up with use-cases where a small /tmp will be a problem.
- any kind of temporary unpack/copy pattern, such as entering
a tar.gz with mc, unpacking of installation files for (mostly proprietary) packages, ...
- vmware uses /tmp/ram0 (immediately unlinked) as guest RAM
backstore
- I personally use /tmp for large files (including ISOs of
DVD I want to burn and delete); maybe I'm the only one doing that...
- I just discovered that my /tmp is currently 3.2GiB. The
majority of the space is for /tmp/kde-myusername/konsole*.tmp (700MiB+520MiB+364MiB+305MiB+117MiB+....), as I run konsole with unlimited scrollback buffer and some shells have easily been open for weeks.
If the feature is implemented and activated by default, I will just turn it off and live happy. It will just be one more thing in the growing list of defaults that should have never been changed. But be prepared to more than "one or two" future bugs of the kind "Oracle can't be installed", "my backup program fails", "the machine slows down to a crawl and only a reboot fixes it", ...
Best regards.
+100
On Thu, May 31, 2012 at 02:57:17PM +0200, Roberto Ragusa wrote:
I suppose that an additional small-tmp (e.g. /tmpram) could be useful for some programs currently using tmp for very small files.
We already have it: /dev/shm
In a double irony, the only user of it on my system is pulseaudio, which seems to be using it instead of /run.
But I agree with your general point that /tmp on tmpfs is a feature searching for a justification, particularly since tmpfs is by default limited to 1/2 of RAM, and on small memory machines, that's not a lot of space.
Rich.
On Thursday, May 31 2012, Ralf Corsepius wrote:
On 05/31/2012 12:45 PM, Pádraig Brady wrote:
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
I couldn't say better.
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.
On 06/01/2012 12:15 AM, Sergio Durigan Junior wrote:
On Thursday, May 31 2012, Ralf Corsepius wrote:
On 05/31/2012 12:45 PM, Pádraig Brady wrote:
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
Now /var/tmp should be "more persistent" which we don't need,
Correct, using /var/tmp is wrong and a mistake.
IMO, advising people to modify their code to using /var/tmp instead of /tmp is absurd and evidence of ignorance towards traditional use of /tmp and the FHS.
I couldn't say better.
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.
Well Ralf didn't impart any info as to why moving to /var/tmp would be a bug. If it's a symlink to /tmp on older systems then there is no change. But if the system /tmp is tmpfs then it would be a bug not to change, which is the new default on debian IIUC. BTW there is a long recent thread debian thread about the issues: http://lists.debian.org/debian-devel/2012/05/thrd3.html#01092
The main issue I see at the moment is that apps have overloaded /tmp for different things and it will take time to tease these things out.
Don't worry I'm not going to jump to anything rashly, but `sort` needs to spool to non RAM, so we'll have to adjust if /tmp is RAM.
cheers, Pádraig.
On Thu, May 31, 2012 at 11:45:36AM +0100, Pádraig Brady wrote:
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
[...]
This will most likely lead to a problem or two with software that isn't happy about /tmp being small.
For example "sort".
This is a good example because `sort` algorithmically needs something below RAM in the memory hierarchy (i.e. bigger), but with the same persistence characteristics of /tmp.
Currently `sort` defaults to $TMPDIR or if not set '/tmp'.
libguestfs has roughly the same problem as 'sort'. It's unfortunate the $TMPDIR doesn't communicate any information about the availability of temporary directories of different types.
I sometimes thing that having optional $PERSISTENT_TMPDIR (a pointer to a directory that persists for some time) and $ONDISK_TMPDIR (a directory that is on a slower medium than RAM) would be useful.
Rich.
Hi.
Firebird sql or the name it used to have before. Not sure if it was default configuration or still behaves the same. But it used to do similar thing sort does for some queries. Anyone? Current example but shipped with F18 from that area?
----- Original Message ----- From: "Pádraig Brady" P@draigBrady.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Cc: "Roberto Ragusa" mail@robertoragusa.it Sent: Thursday, May 31, 2012 12:45:36 PM Subject: Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
[...]
This will most likely lead to a problem or two with software that isn't happy about /tmp being small.
For example "sort".
This is a good example because `sort` algorithmically needs something below RAM in the memory hierarchy (i.e. bigger), but with the same persistence characteristics of /tmp.
Currently `sort` defaults to $TMPDIR or if not set '/tmp'.
Now /var/tmp should be "more persistent" which we don't need, but shouldn't be an issue, but should also not be in RAM and so is more appropriate.
So I'll patch sort to default to /var/tmp rather than /tmp.
I'm a little worried about the general availability of /var/tmp. I know I've created distros without it at least.
For my own reference, sort does support a list of tmp dirs, but it'll need to be tweaked to support non existent dirs:
$ seq 100000 | sort -T /foo -T /tmp -S1M sort: cannot create temporary file in `/foo': No such file or directory
`tac` from coreutils also needs a similar patch.
cheers, Pádraig.
Am 31.05.2012 12:45, schrieb Pádraig Brady:
Currently `sort` defaults to $TMPDIR or if not set '/tmp'.
Now /var/tmp should be "more persistent" which we don't need, but shouldn't be an issue, but should also not be in RAM and so is more appropriate.
So I'll patch sort to default to /var/tmp rather than /tmp
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
in such setups the new behavior results in a full rootfs
also having many virtual machines on a host means you try to allocate as less as possible RAM for each of them which makes the new defaults unuseable and no swapping is not smart in context of virualization
/tmp in RAm is another "change for the sake of the change"
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such).
Am 01.06.2012 18:02, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such).
you did not understand waht i said because you removed the quote for which my anser was targeted
* packages get "fixed" to use /var/tmp instead /tmp * so my /tmp on the seperated disk is mostly unused * i get this craop data back to rootfs
so i have additionally to add a bind-mount using the same disk vor /var/tmp
it will get funny if now all are starting to patch their apps to use /var/tmp - the glory /tmp on tmpfs will mostly not used and the only effect is that many users/admins as also packagers have a lot of work for nothing
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such).
Chris, the problem is that now you have to add a /tmp filesystem, before /tmp was just a normal directory in root.
It means that for fedora 18 upward but not for any other you now have to remember to go and change this default, because honestly /tmp in RAM for a virtual machine is just stupid if you end up using the swap file (btw I disable the swap on my machine often exactly to avoid having the machine trashing and using swap, when I really do not need it to).
It may be a good idea for beefy single user laptops but for anything else it is probably more a regression than help as moving stuff from a normal file system to swap is just going to add memory pressure to the kernel and nothing else.
Simo.
Once upon a time, Simo Sorce simo@redhat.com said:
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such).
Chris, the problem is that now you have to add a /tmp filesystem, before /tmp was just a normal directory in root.
Did you read what I was replying to? My understanding of it was about already using a separate /tmp filesystem.
On Fri, 2012-06-01 at 12:58 -0500, Chris Adams wrote:
Once upon a time, Simo Sorce simo@redhat.com said:
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such).
Chris, the problem is that now you have to add a /tmp filesystem, before /tmp was just a normal directory in root.
Did you read what I was replying to? My understanding of it was about already using a separate /tmp filesystem.
I read it but I have misunderstood. I would hope people that already have /tmp in fstab see no changes.
Simo.
Am 01.06.2012 20:14, schrieb Simo Sorce:
On Fri, 2012-06-01 at 12:58 -0500, Chris Adams wrote:
Once upon a time, Simo Sorce simo@redhat.com said:
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such).
Chris, the problem is that now you have to add a /tmp filesystem, before /tmp was just a normal directory in root.
Did you read what I was replying to? My understanding of it was about already using a separate /tmp filesystem.
I read it but I have misunderstood. I would hope people that already have /tmp in fstab see no changes.
but they do and this is was Chris Adams do not understand because he only reads what he has quoted and not what was the reason for my reply which gives "Did you read what I was replying to" a special taste
patching applications for "/var/tmp rather than /tmp" is a real problem for people which are smart enough to know why they introduced a seperated disk for /tmp
this changes means that the crap no longer goes to /tmp and will hit in the future rootfs because switch to /var/tmp _______________________________
HERE AGAIN THE FULL QUTOE TO GET BACK CONTEXT!
So I'll patch sort to default to /var/tmp rather than /tmp
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
On 06/01/2012 08:56 PM, Reindl Harald wrote:
Am 01.06.2012 20:14, schrieb Simo Sorce:
On Fri, 2012-06-01 at 12:58 -0500, Chris Adams wrote:
Once upon a time, Simo Sorce simo@redhat.com said:
On Fri, 2012-06-01 at 11:02 -0500, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
If you are mounting a filesystem on /tmp, it'll be in /etc/fstab and still work exactly as before (if not, that's a bug and should be treated as such).
Chris, the problem is that now you have to add a /tmp filesystem, before /tmp was just a normal directory in root.
Did you read what I was replying to? My understanding of it was about already using a separate /tmp filesystem.
I read it but I have misunderstood. I would hope people that already have /tmp in fstab see no changes.
but they do and this is was Chris Adams do not understand because he only reads what he has quoted and not what was the reason for my reply which gives "Did you read what I was replying to" a special taste
patching applications for "/var/tmp rather than /tmp" is a real problem for people which are smart enough to know why they introduced a seperated disk for /tmp
this changes means that the crap no longer goes to /tmp and will hit in the future rootfs because switch to /var/tmp _______________________________
HERE AGAIN THE FULL QUTOE TO GET BACK CONTEXT!
So I'll patch sort to default to /var/tmp rather than /tmp
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
So what if _existing_ systems write to /var/tmp in the above setup? /var/tmp is there already so it needs to be handled. Seems like you should link /var/tmp to /tmp to handle that. And/Or you should probably set TMPDIR=/tmp system wide to enforce this non standard setup.
If you do that, then as well as closing the existing loophole, you make the system immune to future changes in this area as apps should honor $TMPDIR before using their defaults of /var/tmp or /tmp or /whatever
cheers, Pádraig.
Am 02.06.2012 00:24, schrieb Pádraig Brady:
On 06/01/2012 08:56 PM, Reindl Harald wrote:
HERE AGAIN THE FULL QUTOE TO GET BACK CONTEXT!
So I'll patch sort to default to /var/tmp rather than /tmp
thank you for breaking setups of well thought virtual machines on expensive SAN storages with a as small as possible rootfs with a own virtual disk for /tmp with new defaults
So what if _existing_ systems write to /var/tmp in the above setup? /var/tmp is there already so it needs to be handled. Seems like you should link /var/tmp to /tmp to handle that. And/Or you should probably set TMPDIR=/tmp system wide to enforce this non standard setup.
If you do that, then as well as closing the existing loophole, you make the system immune to future changes in this area as apps should honor $TMPDIR before using their defaults of /var/tmp or /tmp or /whatever
i for myself do this as example on my workstation all the time because i know exactly how to deal with my setups and that is why i survived all dist-upgrades from FC6 to F16 with yum
the majority of users does not know much about their system
but we are speaking here about a GLOBAL DEFAULT for all users and change of a OS-behavior without a real improvement should be a no-go in cases where the overall impact tends to make things worser - this is the microsoft way!
nobody can imagine how many setups will be randomly broken with this change and how long it takes that the admins of this systems recognize what leads to wired problems from time to time
so the main question remains: why do we randomly change things for a little theoretical improvement while only the work of package-maintainers and increased bugreports destroy the improvement at all?
i will not buy the argument SSD disk because a common page with tips for opütimization showing the line for /etc/fstab and explain the impacts could do the same without change the os behavior for everybody __________________
/mnt/data/.tmp /tmp none bind /mnt/data/.tmp /var/tmp none bind
simply because /mnt/data is /dev/md2 and a RAID10 with 4 TB and my /dev/md1 is only for the rootfs what is a major win for backups or cloning machines efficient
On 05/31/2012 11:45 AM, Pádraig Brady wrote:
On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
[...]
This will most likely lead to a problem or two with software that isn't happy about /tmp being small.
For example "sort".
This is a good example because `sort` algorithmically needs something below RAM in the memory hierarchy (i.e. bigger), but with the same persistence characteristics of /tmp.
Currently `sort` defaults to $TMPDIR or if not set '/tmp'.
Now /var/tmp should be "more persistent" which we don't need, but shouldn't be an issue, but should also not be in RAM and so is more appropriate.
One possible issue is that stale sort tmp files could persist in /var/tmp for 30 days even after a reboot.
I'm going to err on the side of leaving sort(1) as is and using /tmp by default, as detailed at: http://lists.gnu.org/archive/html/coreutils/2012-09/msg00139.html
In summary, sort(1) only needs stateless storage, so lets keep it more abstract and default to /tmp, rather than worrying about system specifics.
cheers, Pádraig.
On Thu, Sep 13, 2012 at 3:54 AM, Pádraig Brady P@draigbrady.com wrote:
One possible issue is that stale sort tmp files could persist in /var/tmp for 30 days even after a reboot.
I'm going to err on the side of leaving sort(1) as is and using /tmp by default, as detailed at: http://lists.gnu.org/archive/html/coreutils/2012-09/msg00139.html
In summary, sort(1) only needs stateless storage, so lets keep it more abstract and default to /tmp, rather than worrying about system specifics.
It also needs storage larger than the available virtual memory, doesn't it?. AFAICS using /tmp is more or less equivalent to specifying --buffer-size=[infinity] , which doesn't make sense for sort.
I do appreciate that there is nothing sort can do to get a reliable cross-platform default. Mirek
On 09/13/2012 03:54 AM, Pádraig Brady wrote:
I'm going to err on the side of leaving sort(1) as is and using /tmp by default, as detailed at: http://lists.gnu.org/archive/html/coreutils/2012-09/msg00139.html
This is the perfect solution for all the people who will switch /tmp back to disk immediately after installation.
On Thu, 2012-05-31 at 02:40 +0200, Lennart Poettering wrote:
Heya!
Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18.
For details please see this feature page:
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs
If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default.
This will most likely lead to a problem or two with software that isn't happy about /tmp being small. We have created a tracker bug to keep track of this:
https://bugzilla.redhat.com/show_bug.cgi?id=826015
If you have identified a bug that is triggered by /tmp being on tmpfs now, please add it to this tracker bug!
For a bit of background on all of this and recommendations for developers, please see:
Lennart is there any smarts about it based on available RAM ? I regularly install VMs with < 1GiB of RAM and /tmp in RAM would make them unusable. On a development laptop with 4GiB of RAM and many VMs I would still find /tmp in RAM a bit of a stretch, but whatever.
So is there any smarts there that disable this feature when there is little RAM available from the get go ?
Simo.
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Ales Ledvinka -
Alexey I. Froloff -
Andrew McNabb -
Brian Wheeler -
Bruno Wolff III -
Chris Adams -
Chris Lumens -
David Sommerseth -
Dennis Jacobfeuerborn -
DJ Delorie -
Frank Murphy -
Garrett Holmstrom -
Gerry Reno -
Gregory Maxwell -
Guido Grazioli -
Harald Hoyer -
Jef Spaleta -
Joel Rees -
Jon Ciesla -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
Michael Cronenworth -
Miloslav Trmač -
Nathanael D. Noblet -
Olav Vitters -
Peter Jones -
Pádraig Brady -
Ralf Corsepius -
Reindl Harald -
Richard W.M. Jones -
Roberto Ragusa -
Roman Rakus -
Sergio Durigan Junior -
Simo Sorce -
Steve Clark -
Tomas Mraz