* Ben Hutchings <ben@decadent.org.uk> [120527 17:25]:
> Creating arbitrarily large temporary files outside the user's home
> directory is generally going to be unreliable.

The only thing more unreliable than that is creating arbitrary large
file in user's home directory. If it is not supposed to be persistent
data that is available on every node the user can log in, then it does
not belong into the home directory (unless the user explicitly choose
to set TMPDIR there). The home directory can be quite slow (because
being remote, being encrypted, ...) and quite scarce (permanent storage
on server discs with redudancy and backup strategies is not that cheap).

Unless a program is explicitly told otherwise, temporary files belong
to TMPDIR and if that is not set to /tmp. (or any subdirectory thereof
the programs like to create). If that is too small, then it is too
small. The admin is able to configure /tmp differently, the user is
able to set TMPDIR differently.

my 0.02:
I personally think having tmpdir on /tmp might be a good default for
new systems. If systems get changed to that from something else on
upgrade without asking, I consider that quite an ugly bug.

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120528084732.GA4777@client.brlink.eu">http://lists.debian.org/20120528084732.GA4777@client.brlink.eu

On Mon, May 28, 2012 at 01:59:24AM +0100, Ben Hutchings wrote:

I don't recall that being common practice on any multi-user Unix-like
system I've used. (It's also not something a Windows user would expect,


Well, it was back in my university days, and it still is where I work.
Maybe „multi-user� is wrong, but telling other user that the ISO lies on
my system in /tmp is much easier than to tell them a location in my $HOME
and to make sure they can access ist.



as they already get per-user temporary directories.)


One of the first things I do after a Windows installation is to create
c: emp. ;-)


Shade and sweet water!

Stephan

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

On 05/28/2012 04:46 AM, Serge wrote:
> The truth is that tmpfs IS FASTER in some cases. The problem is that
> *nobody* can notice that on *real* applications.
Serge, I'm on your side of the discussion, but the above is simply
not truth. And by the way, that's not the issue. The issue is potential
breakage, which we want to avoid *at all costs*.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FC39E64.10504@debian.org">http://lists.debian.org/4FC39E64.10504@debian.org

On 28/05/12 17:48, Thomas Goirand wrote:
> On 05/28/2012 04:46 AM, Serge wrote:
>> The truth is that tmpfs IS FASTER in some cases. The problem is that
>> *nobody* can notice that on *real* applications.
> Serge, I'm on your side of the discussion, but the above is simply
> not truth. And by the way, that's not the issue. The issue is potential
> breakage, which we want to avoid *at all costs*.
>
> Thomas
>
>

I think this is a valid point.

We should know what applications and workloads get a _measurable_
benefit by using tmpfs for /tmp instead of using a normal filesystem.

If we are optimizing things for just a synthetic benchmark that does
fsyncs on lot of small files then we are loosing the perspective of reality.

We should have things on the table like the following to support the
idea that tmpfs really gives any performance benefit in the day-to-day
real-world-tasks of people and not only on synthetic benchmarks

- Program X is a % faster when using tmpfs for /tmp
- Compiling the Linux Kernel is a % faster when using tmpfs for /tmp
- Task Z is a % faster when using tmpfs for /tmp
- [...]

Regards!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
Carlos Alberto Lopez Perez http://neutrino.es
Igalia - Free Software Engineering http://www.igalia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~

[Ben Hutchings]
> We should be thinking about implementing per-user temporary directories
> and making sure that programs respect $TMPDIR.

Yes, per-user temp directories is a good idea. Installing the
libpam-tmpdir package enable this by default, and beside some problems
with the root user (bad TMPDIR is inherited when I restart services
using /etc/init.d/ scripts), it work well. Perhaps it should be
extended to allow the directory to be below ~/ instead of below
/tmp/.

It make it very easy to spot the programs not respecting $TMPDIR.

> (On Linux it's also possible to give each user a different /tmp
> through mount namespaces. I'm not sure whether that's compatible
> with historical use of /tmp by the X window system.)

This sound a bit more scary, yes.
--
Happy hacking
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 2fltxz0p18t.fsf@login2.uio.no">http://lists.debian.org/2fltxz0p18t.fsf@login2.uio.no

On 05/28/2012 04:47 PM, Bernhard R. Link wrote:
> I personally think having tmpdir on /tmp might be a good default for
> new systems. If systems get changed to that from something else on
> upgrade without asking, I consider that quite an ugly bug.
>
And you're not the only one. It seems that at least one member
of the release team (IMO rightly) think this way as well. See #674517.
BTW, I don't think it was possible to hide the RAMTMP variable/switch
better than it is right now in SID...

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FC3D1FF.8020403@debian.org">http://lists.debian.org/4FC3D1FF.8020403@debian.org

On 05/29/2012 03:13 AM, Petter Reinholdtsen wrote:
> Perhaps it should be
> extended to allow the directory to be below ~/ instead of below
> /tmp/.
>
I don't think so. As other pointed out, your /home could be
remote (over NFS?), and then slow, while /tmp is normally
on your local machine, so moving the temp folder in ~/ will
potentially slow them down, and break quota.

What's the folder structure in /tmp then? /tmp/<something>/$USER?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FC44D4E.6030509@debian.org">http://lists.debian.org/4FC44D4E.6030509@debian.org

]] Thomas Goirand

> What's the folder structure in /tmp then? /tmp/<something>/$USER?

/tmp/user/$UID is the default. It can be overridden, but not in a
manner that's compatible with Petter's suggestion.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx4rvblx.fsf@xoog.err.no">http://lists.debian.org/87mx4rvblx.fsf@xoog.err.no

On Tue, 2012-05-29 at 12:15 +0800, Thomas Goirand wrote:
> What's the folder structure in /tmp then? /tmp/<something>/$USER?

It's the Wild West over there. You'll often see something
like /tmp/$procname/$pid/blah or /tmp/$procname/$user/blah, or
just /tmp/$some_hash_of_who_knows_what/blah.

FHS is uncharacteristically laconic:

http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES

Weldon




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1338267368.2617.0.camel@minerva">http://lists.debian.org/1338267368.2617.0.camel@minerva

Thomas Goirand <zigo@debian.org> writes:
>> Perhaps it should be
>> extended to allow the directory to be below ~/ instead of below
>> /tmp/.
>>
> I don't think so. As other pointed out, your /home could be
> remote (over NFS?), and then slow, while /tmp is normally
> on your local machine, so moving the temp folder in ~/ will
> potentially slow them down, and break quota.

... yeah, my homedir is in NFS, and I get no end of grief from the
bazillion packages in debian that blithely cache vast quantities of
(often very uninteresting) data in random subdirs of $HOME... and then
expect accessing it to be very fast....

:[

-miles

--
Year, n. A period of three hundred and sixty-five disappointments.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d35na73z.fsf@catnip.gol.com">http://lists.debian.org/87d35na73z.fsf@catnip.gol.com