Re: Moving /tmp to tmpfs makes it useless
Le Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh a écrit :
>
> I haven't got anything particularly new to add to the discussion here.
> But I would like to refer you to the previous discussion on the
> topic. I am well aware that the default does not satisfy all use
> cases, but that's simply not possible for this problem. The best we
> can do is have a good default. That could be by improving the
> tmpfs default sizes and behaviour (my preferred solution). It could
> be by defaulting to not using a tmpfs. However, the majority of
> software which finds the tmpfs too small has unreasonable expectations
> of what can be expected to be available (by default).
Dear Roger,
thanks for your patient work.
As you explained, with latest versions of sysvinit (currently un experimetnal),
20% of the whole memory (RAM + swap) will be used for /tmp. This will give a
couple of gigabytes in systems with 8 Gb RAM + 8 Gb swap, which may be
borderline when working with big files. On my system at work, I often need to
sort big files, and I think that even coreutil's sort program does not check in
advance if there will be enough space in /tmp. I often lose some time for
forgetting to set TMPDIR before running a command.
How about doing the reverse and defind the amount of memory that /tmp will
not use ?
This limit could be in the range of what is necessary to avoid a GNOME session
to be killed, and fall back to a percentage if the memory is lower than that
treshold ? Thhe current system of using a percentage of the memory, reduces
the impact to the recommendation of increasing the swap size. For the moment,
if one wants to give 1 Gb more to /tmp, he would have to increase the swap by 5
Gb.
Have a nice week-end.
PS: I think that it would be great if people could reduce the speed at which
they send messages. We are about to release a "diversity statement", but the
way this list is used, only males fluent in English and with a strong opintion
express themselves.
PPS: With the advent of virtualisation and cloud computing, we will definitely
benefit stopping the applications to use /tmp as if it were a directory with a
large amount of space. One of the reasons I do not set TMPDIR by default in my
environment is that I would lose the benefit of having cruft cleaned at reboot.
What we are perhaps missign here is a couple of sound recommendations, plus
some facilities such as a temporary directory ready for the user somewhere,
which would function like /tmp does. Something like getting XDG_SESSION_TMPDIR
for free after login, without having to think on how to implement it.
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: