[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary: Moving /tmp to tmpfs makes it useless



On Sat, Jun 23, 2012 at 11:43:03PM +0200, Wouter Verhelst wrote:
On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:
So most of your Debian systems have several users working at the
same time on the same system? Okay, then you have a different user
base.
"webserver".

Sorry, I ignored servers. I don’t think that anyone will install a server with a default installation because you have more special cases (separate database partition, separate mailbox partition, etc.).

I still think that the SSD problem is not a valid concern as long as
we don’t have solutions for /var and log daemons. There is more
traffic in /var than in /tmp.
Yes, /var produces changes to storage, too, but that doesn't mean we
shouldn't optimize /tmp because we can't optimize /var. That makes no
sense.

But if you move the /tmp access away (see below), then you don’t need tmpfs at all.

I'm not saying we should "optimize for SSDs". I'm just saying that
storing on tmpfs is beneficial for SSDs.

See below.

[/ramtmp not a good idea]
Well, why?
Because it would end up being a directory that nearly nobody would use
directly. Those who want to use a ramdisk will just remove that
directory (or make it a symlink) and mount /tmp on tmpfs instead, and
those who don't want to use it will probably just ignore it.

I don’t think so. Having a disk based /tmp that gets cleaned after reboots and having a ramdisk /ramtmp will give you the choice which directory you want to use for a special application. Your video encoder example could certainly use /ramtmp, even if you have to patch the encoder in Debian to do so. The temporary video files of the web browser can stay in /tmp, as well as big powerpoint temporary files of libreoffice.

And I don’t think that most user only want one solution.

Also, if deciding on a reasonable default for /tmp is difficult, think
about deciding on a reasonable default for individual packages. That's
going to be even harder.

Sometimes maybe. But you will certainly get some hundred of megabytes of tmpfs space. So if you know that your temporary file will be smaller, you can use /ramtmp. Besides we can look for other places to use tmpfs. What about /var/lib/amavis/tmp? The initscript could create a tmpfs.

Meanwhile, you've got a non-FHS directory on your system that is of no
immediate use.

Your later suggested /store as a user /tmp replacement is a non-FHS directory as well.

/tmp has always been about 10-20GB big, because I expect users to
store big temporary images in /tmp. I won’t get this with tmpfs and
I would have to train the users to change their behaviour.
I believe this is part of our disagreement: I don't think system-wide
directories are meant for users to use directly. In other words, I don't
think users should put large downloads in /tmp; instead, they should put

Now this thread is the first time someone mentions that /tmp should not be used by users but is only for system services. I don’t know of any documentation to support this claim. On the contrary all documentation about Unix/Linux I know say that /tmp is for all temporary files.

But let’s say, /tmp is only for system services. Temporary user files belong to $HOME/tmp (which would be a special case in Debian only). So besides from teaching all users to not use /tmp, we need a cleaning job for $HOME/tmp and have to patch all software (browser, libreoffice, libpam-tmp, etc) to use the new tmp. But then most of your examples for tmpfs will be void because no user will use it. Your video encoder is a user application, so the temporary statistic file will go to $HOME/tmp, not to /tmp.

And if you say that noone will use a combination of /tmp and /ramtmp, why do you think that someone will suddenly use a combination of /tmp (tmpfs) and $HOME/tmp?

So I still think that my /ramtmp additional to /tmp are for now the best of both worlds without the risk of breaking applications and user expectations.

	Stephan

--
| Stephan Seitz          E-Mail: stse@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Reply to: