On Thu, Jan 21, 2016 at 11:14:21AM +0100, Martin Pitt wrote:
> Robie Basak [2016-01-21 9:56 +0000]:
> > I think we need a single canonical (small c) answer. Let's say that I'm
> > an upstream maintainer of a project that currently uses large amounts of
> > space in /tmp (say debdiff on kernel sources, for example). A user files
> > a bug that his machine now explodes when he uses my program. How should
> > I fix the bug?
>
> How is that any different than what we have now? systems with more
> memory than space on the root partition do exist [1], systems with
> /tmp on tmpfs do exist. We are *not* going from "/tmp has indefinite
> space" to "/tmp has little space", we are just changing the limit (not
> necessarily downwards even!) to a differently fuzzy definition.
Right - it's differently fuzzy, so affects a different set of users and
also a different set of upstream project use cases.
For some use cases, I think it's clear that RAM-based won't do, or
otherwise isn't acceptable. In the common case of / being the one big
system filesystem (doesn't our installer do that by default?), this
amounts to a massive decrease in the available space in /tmp. So for
some upstream use cases, we are clearly going from "you can use /tmp" to
"you cannot use /tmp".
For cases where users override the default partitioning choices (be it
the desktop installer or what you get by default on a cloud instance),
it's reasonable to expect the user to have to do some tuning around
filesystem use to work around any breakage this customisation causes,
for example by using Dustin's suggestions.
But for the default case, I think it's important that we don't cause
anything additional to break, or if we must do, that there is a clear
path to follow for upstreams that know that they need a ton of
disk-backed tmp space in order to make sure that the default case
doesn't break for users.
> If you program dumps vast amounts of data into /tmp, that is a problem
> somewhere no matter what you do. /var/tmp/ has traditionally had a
> better chance of carrying large files (but of course also not
> guaranteed).
On dumping vast amounts into /tmp being a problem already, I think I
disagree with you here because 1) they exist; 2) they work in the
default case currently; and 3) they will break (in the default case)
with a change of /tmp to tmpfs.
I think any solution needs to provide a clear answer for upstreams that
have this use case. You say "/var/tmp/ has traditionally had a better
chance of carrying large files". If this is true across the entire
ecosystem that upstreams care about (not just Ubuntu), then I'd be happy
that this is a clear answer for upstreams.
They would lose easy user tunability via TMPDIR though. So should we
define a LARGETMPDIR and point it to /var/tmp, so that upstreams can use
${LARGETMPDIR:-/var/tmp} and thus get the same tunability they have with
${TMPDIR:-/tmp} today? If this is the case, perhaps we need wider
agreement for this, not just within Ubuntu, so this is more effective
for upstreams to use?
Robie
