11–20 of 85 posts
Minor disagreement about the following: "Everyone must worry about whether their files need to survive a reboot" I believe there was never such expectation of /tmp. On many systems it's being wiped periodically or even when the user's last session ends. The example app(s) that use /tmp for drafts need(s) to be fixed.
It makes sense in certain cases to use tmpfs for /tmp. However, I'm not sure this is on desktop machines, which (generally) have lower RAM than servers thrashing their /tmp directories.
Even in that case, using tmpfs on /tmp sounds like band aid. If there are applications that suffer performance because stuff it puts in /tmp , then change those applications - possibly by using an application specific tmpfs , or a new system wide tmpfs that doesn't overload something as ubiquitous /tmp
"Everyone must now be careful never to store a file in /tmp that might grow large" If you're going to trash my /tmp with gigantic files please don't. Really "it’s better to fix the filesystem to make it faster" Yes, let's spend adding more complexity to the file system to work out every /tmp abuser out there. But his original point was avoiding adding complexity in the first place So basically, he contradicts himself…
Better to add complexity once, in the filesystem, than in every program that writes to it.
Minor disagreement about the following: "Everyone must worry about whether their files need to survive a reboot" I believe there was never such expectation of /tmp. On many systems it's being wiped periodically or even when the user's last session ends. The example app(s) that use /tmp for drafts need(s) to be fixed.
Surely thats what /var/tmp is intended for.
Not quite. There are many much more difficult problems in a competitive optimizing compiler before hitting that step.
You can get reasonable results from even a linear scan allocator, which is simple.
9 times out of 10, tmpfs is explicitly not for use mounted as /tmp. The only obvious exception I can think of are cluster nodes where the workload is specialized and the node has no local storage whatsoever. I guess it only takes one silly person to connect "tmp" in the name to "/tmp", and the rest is history.
debugfs is mounted on /sys/kernel/debug
securityfs is mounted on /sys/kernel/security
So tmpfs is mounted on /tmp? Can see that...
"Everyone must now be careful never to store a file in /tmp that might grow large" If you're going to trash my /tmp with gigantic files please don't. Really "it’s better to fix the filesystem to make it faster" Yes, let's spend adding more complexity to the file system to work out every /tmp abuser out there. But his original point was avoiding adding complexity in the first place So basically, he contradicts himself…
I mount /tmp as a tmpfs for almost exactly this reason. I have an always-on home server/HTPC that runs the OS off of a small (40 GB) SSD, and I don't want to wear down the SSD with writes to /tmp, /var/tmp, /var/run, /var/log, etc. In theory, I don't want any writes at all, unless the thing is actually doing something useful. So I simply threw in 2GB extra RAM and mounted all these temporary/logging directories as tmpfs. Periodically (and on reboot) I zip the logs up and copy them to a backup directory just in case something fails.
Of course this runs the risk of losing temporary data and logs whenever the server goes down, but that's a trade-off I'm willing to make. It's been running just fine for over 2 years now. I'd do the same thing straight away if I ever need to set up some similar system.
Minor disagreement about the following: "Everyone must worry about whether their files need to survive a reboot" I believe there was never such expectation of /tmp. On many systems it's being wiped periodically or even when the user's last session ends. The example app(s) that use /tmp for drafts need(s) to be fixed.
Sure, but if the power goes down, there's at least a chance that I may be able to find that long email I was writing. With /tmp on tmpfs, it's gone.
Minor disagreement about the following: "Everyone must worry about whether their files need to survive a reboot" I believe there was never such expectation of /tmp. On many systems it's being wiped periodically or even when the user's last session ends. The example app(s) that use /tmp for drafts need(s) to be fixed.
Sure, but if the power goes down, there's at least a chance that I may be able to find that long email I was writing. With /tmp on tmpfs, it's gone.
Although I agree with your points, I find that the design of one application alone cannot be a justifiable point.