Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ben Hutchings]

On Mon, 2016-07-25 at 14:27 +0530, Ritesh Raj Sarraf wrote:
> Hello All,
> 
> On Thu, 2016-07-21 at 20:41 +0530, Ritesh Raj Sarraf wrote:
> > On Thu, 2016-07-21 at 13:38 +0100, Ian Jackson wrote:
> > > 
> > > You are using `survives reboots' as a proxy for `on disk'; and using
> > > `on disk' as a proxy for `has enough space for large amounts of data'.
> > 
> > Yes. :-)
> > 
> > > 
> > > I don't think this is a good approach.
> > > 
> > > It's true that /tmp has traditionally been smaller than /var/tmp,
> > > partly as an accident of partition and filesystem layout.
> > > 
> > > As a practical matter, there are big performance gains to be had from
> > > not requiring across-reboot (and, particularly, across-crash)
> > > persistence.
> > > 
> > > Perhaps the right answer is instead that we should simply configure
> > > more swap by default ?  (IIRC tmpfs data can be swapped.)
> > 
> > Yes. But that's not the default in our setups. Perhaps next step is to file 
> > a
> > wishlist bug report.
> > 
> > 
> 
> Lots of folks on the list mentioned about swap. I wasn't very clear on how
> that'd work. So I reached out to the tmpfs maintainer.

It is a shame that you didn't read more carefully what he said.

> From what  Hugh explained
> (email attached), the size allocated to tmpfs (or rather /tmp on tmpfs) does 
> not
> change. It is a fixed size (kernel default to 50% of RAM).

That is a *limit* on the size allocated to it.

> The benefit of tmpfs over ramfs (previous implementation) is that
> tmpfs can be resized live.
[...]

He said ramdisk, not ramfs.  A ramdisk has a fixed size.  A ramfs has a
variable size, like tmpfs, but its files are never swapped.  It's
intended for processors without an MMU.

Ben.

-- 

Ben Hutchings
Knowledge is power.  France is bacon.


signature.asc
Description: This is a digitally signed message part

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Ian Jackson]

Vincent Lefevre writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR ? 
[and 1 more messages]"):
> On an older laptop, I had 4 GB RAM, and under normal conditions,
> I was using only around 1 GB. Swap was used only in two cases:
> 
> 1. Because Firefox was taking more than 4 GB after some time, but
> in this case, the system was more or less frozen. So, the only thing
> I could do was to kill Firefox from a terminal, which was taking me
> several minutes... I ended up by using a wrapper script that did:
> 
>   ulimit -v 4096000
>   exec /usr/bin/firefox "$@"
> 
> so that Firefox would crash instead of freezing the system. Now, it
> seems that Firefox has improved and no longer take so much memory.

You may find that changing the io scheduler from cfq (which is
appallingly bad) to deadline helps.

> 2. Due to bugs in my programs, or something similar. Ditto, I would
> have preferred a crash than a frozen system.

Perhaps I have a different use pattern.

Ian.

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

Hello All,

On Thu, 2016-07-21 at 20:41 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2016-07-21 at 13:38 +0100, Ian Jackson wrote:
> > 
> > You are using `survives reboots' as a proxy for `on disk'; and using
> > `on disk' as a proxy for `has enough space for large amounts of data'.
> 
> Yes. :-)
> 
> > 
> > I don't think this is a good approach.
> > 
> > It's true that /tmp has traditionally been smaller than /var/tmp,
> > partly as an accident of partition and filesystem layout.
> > 
> > As a practical matter, there are big performance gains to be had from
> > not requiring across-reboot (and, particularly, across-crash)
> > persistence.
> > 
> > Perhaps the right answer is instead that we should simply configure
> > more swap by default ?  (IIRC tmpfs data can be swapped.)
> 
> Yes. But that's not the default in our setups. Perhaps next step is to file a
> wishlist bug report.
> 
> 

Lots of folks on the list mentioned about swap. I wasn't very clear on how
that'd work. So I reached out to the tmpfs maintainer. From what  Hugh explained
(email attached), the size allocated to tmpfs (or rather /tmp on tmpfs) does not
change. It is a fixed size (kernel default to 50% of RAM). The benefit of tmpfs
over ramfs (previous implementation) is that tmpfs can be resized live.


So that said, I (still) wonder if there should be a [D]TMPDIR ?
Because RAM is limited. But having /tmp on tmpfs has obvious benefits.
And in the current form, lots of applications depend on /tmp for scratch space,
and they may break.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System--- Begin Message ---
On Mon, 25 Jul 2016, Ritesh Raj Sarraf wrote:
> 
> I am writing to you because you are listed as Maintainers for the tmpfs file
> system in the Linux kernel.
> 
> 
> Recently, I have had a bug in a general purpose application, where it ran out 
> of
> space in $TMPDIR. As is common, these days, most people vote for /tmp on 
> tmpfs,
> for obviously good reasons (performance, efficiency etc).
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831998

I think the problem is not so much with tmpfs itself, as with tmpfs
defaulting to a smaller size (half of RAM) of filesystem than would
be common on disk.  You would see the same problems with a 3.7G
disk partition mounted on /tmp; but tmpfs is easier to resize.

Looks like it didn't need much more space, try
$ sudo mount -o remount,size=4G /tmp

Or, perhaps it's just that something else left its forgotten junk
behind in /tmp, and you need to do some cleanup.

> 
> 
> On bringing this bug, and the topic of "TMPDIR on tmpfs" on Debian-Devel,
> there's one comment which wasn't clear to me. Hence this email to you.
> 
> Even in the description below about tmpfs, it says, ". to accommodate the
> files it contains and is able to swap unneeded pages out to swap space."

It writes of growing and shrinking there, to distinguish the behavior of
tmpfs from that of the original ramdisks we had in v2.4: where the maximum
RAM was assigned to them at startup IIRC.  Then ramdisks were changed to
allocate on demand during v2.6.  But ramdisks have never used swap, so
cannot shrink their RAM use after it has been allocated.

And yes, it is confusing to write of growing and shrinking, when this
growth and shrinkage in RAM use makes no difference to the filesystem
size itself: that limit remains the same throughout, unless you choose
to change it with a remount, as suggested above.

> 
> When we say "swap unneeded pages out to swap space", as I understand, what is
> being referred as "Swappable" here is any process in the kernel's namespace. 
> And
> not referring to processes associated with /tmp ? Because those mostly will be
> active processes.

No, it's not talking about processes there.  Under memory pressure
page reclaim uses swap for storing pages of process anonymous memory,
and for storing pages of tmpfs file memory, until it's needed in RAM again.
Similar mechanism is used for paging in both cases, and all these pages are
tracked on the same lists, but processes and files are swapped independently.

> 
> The way I observed, it looks like whatever "/tmp on tmpfs" is capped at, from
> the VFS point of view, is the standard limit for processes accessing files in
> /tmp. And that file system view and limitations won't change (in effect to 
> other
> processes being swapped or not).

Correct, the use of swap does not affect the filesystem size limit at all.

Hugh

> 
> Consider this example:
> 
> rrs@chutzpah:~$ df -h /tmp/
> Filesystem  Size  Used Avail Use% Mounted on
> tmpfs   3.7G  3.7M  3.7G   1% /tmp
> 
> rrs@chutzpah:~$ dd if=/dev/zero of=/tmp/foo.img bs=1M count=4000
> dd: error writing '/tmp/foo.img': No space left on device
> 3691+0 records in
> 3690+0 records out
> 3869605888 bytes (3.9 GB, 3.6 GiB) copied, 1.12808 s, 3.4 GB/s
> 
> rrs@chutzpah:~$ free -m
>   totalusedfree  shared  buff/cache   
> 

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Clint Byrum]

Excerpts from Gabor Gombas's message of 2016-07-21 21:22:02 +0200:
> On Thu, Jul 21, 2016 at 04:06:26PM +0300, Dmitry Bogatov wrote:
> 
> > For example, I, as happy owner of 8GB RAM, is perfectly fine with 3GB
> > in /tmp, because I actually use less then 1Gb. On other hand, would I
> > start 50 instances of Firefox, Gimp and other stuff, I would object
> > putting 3GB in my /tmp, since it would make system swap.
> 
> I don't quite buy your argument. If you want to write 3GB to disk, then
> you need to write 3GB to disk - it's the same amount of data, whether
> you call it "filesystem" or "swap". But if you use a real filesystem to
> store that data, then you will also have to deal metadata, which needs
> to be protected from crashes so you want to flush caches from time to
> time, which is expensive. tmpfs does not have such requirements, so it
> should give you better performance. I guess someone should measure it...
> 
> Gabor

The metadata is tiny and heavily optimized. That, and flushes to disk
are well tuned and optimized in the VFS layer. The elevator is well
tuned for access like this, and programs expect this performance when
dealing with te,porary files.

Swap, meanwhile, is largely synchronous, and could affect any part of
the system not locked into RAM. Programmers aren't as prepared for a
read from memory to block on paging in. So, IMO, the more swap pressure
you put on the system by filling up tmpfs mounts, the more unpredictable
your system will be, and that's far worse than being a few percentage
points slower on temp file operations.

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Josh Triplett]

Tollef Fog Heen wrote:
> There's a perfectly fine way to specify that you want a tmpfs mount of a
> particular size on /tmp: /etc/fstab.  I don't know why sysv-rc added
> another special extension for this rather than just letting people use
> the standard interface.

sysv-rc already needed code to mount various other tmpfs filesystems,
such as /run and /run/shm.

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Tollef Fog Heen]

]] Ritesh Raj Sarraf 

> On Thu, 2016-07-21 at 15:42 +0200, Vincent Lefevre wrote:
> > On 2016-07-21 15:24:10 +0200, Philip Hands wrote:
> > > It's configurable.
> > > 
> > > See TMPFS_SIZE in /etc/defaults/tmpfs
> > 
> > If you mean /etc/default/tmpfs, it doesn't work with systemd
> > (as documented), and there's the global problem with swap.
> 
> And I was thinking of asking the same to the systemd maintainers. So thanks 
> for
> mentioning this. Though I wish systemd honored values from these files.

There's a perfectly fine way to specify that you want a tmpfs mount of a
particular size on /tmp: /etc/fstab.  I don't know why sysv-rc added
another special extension for this rather than just letting people use
the standard interface.

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

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Tollef Fog Heen]

]] Vincent Lefevre 

> What's the problem if swap is *never* used under normal conditions?
> On current machines, I typically use less than 10% the amount of
> physical RAM.
> 
> On an older laptop, I had 4 GB RAM, and under normal conditions,
> I was using only around 1 GB. Swap was used only in two cases:
> 
> 1. Because Firefox was taking more than 4 GB after some time, but
> in this case, the system was more or less frozen. So, the only thing
> I could do was to kill Firefox from a terminal, which was taking me
> several minutes... I ended up by using a wrapper script that did:

On a multi-socket system, you might well end up swapping instead of
using all the memory in this particular case, since you get hit by the
default NUMA allocation policy.  (Unless that's changed recently.)

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

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Vincent Lefevre]

On 2016-07-21 21:53:11 +0100, Ben Hutchings wrote:
> It's true that if the system has to swap a lot of data out then it is
> likely to become unresponsive.  However, I think there are good reasons
> to enable a small amount of swap space:
> 
> - Some long-running applications have, effectively, memory leaks of a
> bounded size that can profitably be swapped out
> - The exact same problem can occur with memory-mapped files, and by
> disabling swap you prevent the kernel from balancing demand for
> anonymous and file-backed memory

Unfortunately, AFAIK, one cannot tell the kernel to use swap only
in these cases.

I'd prefer to buy "a small amount" of additional RAM that would
replace swap in these cases, and avoid a system freeze if something
goes wrong.

Swap could actually be interesting if the swap/RAM ratio were
important, say 10 or more, because in such a case one couldn't
avoid swap by buying more RAM (too expensive or not possible).
But this means that one should have control of how swap is used.
To give an example, I think that /tmp = 4 GB tmpfs + 80 GB swap
could be a better solution than /tmp being a part of the root
filesystem. Something like that.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Vincent Lefevre]

> Vincent Lefevre writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR 
> ?"):
> > On 2016-07-21 18:19:43 +0530, Ritesh Raj Sarraf wrote:
> > > Swap will come into effect when the kernel needs more memory.
> > 
> > Anyway, even if it had worked, swap should not be a solution for the
> > limited /tmp size. The reason is that enabling swap can make the whole
> > system freeze for several dozens of minutes when a program misbehaves.
> > A misbehaving program should crash, not freeze the whole system.
> 
> Uhhh.  You run your systems with no swap at all ?

What's the problem if swap is *never* used under normal conditions?
On current machines, I typically use less than 10% the amount of
physical RAM.

On an older laptop, I had 4 GB RAM, and under normal conditions,
I was using only around 1 GB. Swap was used only in two cases:

1. Because Firefox was taking more than 4 GB after some time, but
in this case, the system was more or less frozen. So, the only thing
I could do was to kill Firefox from a terminal, which was taking me
several minutes... I ended up by using a wrapper script that did:

  ulimit -v 4096000
  exec /usr/bin/firefox "$@"

so that Firefox would crash instead of freezing the system. Now, it
seems that Firefox has improved and no longer take so much memory.

2. Due to bugs in my programs, or something similar. Ditto, I would
have preferred a crash than a frozen system.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ben Hutchings]

On Thu, 2016-07-21 at 21:22 +0200, Gabor Gombas wrote:
> On Thu, Jul 21, 2016 at 04:06:26PM +0300, Dmitry Bogatov wrote:
> 
> > For example, I, as happy owner of 8GB RAM, is perfectly fine with 3GB
> > in /tmp, because I actually use less then 1Gb. On other hand, would I
> > start 50 instances of Firefox, Gimp and other stuff, I would object
> > putting 3GB in my /tmp, since it would make system swap.
> 
> I don't quite buy your argument. If you want to write 3GB to disk, then
> you need to write 3GB to disk - it's the same amount of data, whether
> you call it "filesystem" or "swap". But if you use a real filesystem to
> store that data, then you will also have to deal metadata, which needs
> to be protected from crashes so you want to flush caches from time to
> time, which is expensive. tmpfs does not have such requirements, so it
> should give you better performance. I guess someone should measure it...

I'm not sure the performance comparison is quite as simple as this.
Commonly used filesystems try to avoid fragmentation of files, but
AFAIK there's nothing to prevent fragmentation of tmpfs files in swap.
So reading a file back from swap can involve more seeks than doing the
same from a filesystem.

Ben.

-- 

Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Ben Hutchings]

On Thu, 2016-07-21 at 11:40 -0700, Russ Allbery wrote:
> Ian Jackson  writes:
> 
> > Uhhh.  You run your systems with no swap at all ?
> 
> > That's your prerogative, of course.  But it's far from a default (or
> > recommended) configuration.  I think that if you configure your system
> > without swap, it is up to you do whatever else is necessary to make it
> > work.  That might involve making /tmp not be on a tmpfs (if it is the
> > default for some reason).
> 
> I never use swap on servers any more.  My experience is that swap is so
> slow that if the system starts using swap, the services are all
> essentially down anyway,

It's true that if the system has to swap a lot of data out then it is
likely to become unresponsive.  However, I think there are good reasons
to enable a small amount of swap space:

- Some long-running applications have, effectively, memory leaks of a
bounded size that can profitably be swapped out
- The exact same problem can occur with memory-mapped files, and by
disabling swap you prevent the kernel from balancing demand for
anonymous and file-backed memory

Linux used to have the problem that allocating multi-page blocks
(commonly needed on architectures with 4K pages) could require
reclaiming single pages in the way.  This is much less of an issue now
that the VM manager implements compaction (since 2.6.35).

In some kernels and configurations, forking a large process requires
reserving memory for another copy of all its anonymous pages, so it's
more likely to fail if there's no swap available.  I don't think this
is an issue with the default overcommit setting in Linux, though.

[...]
> It's a lot easier to tolerate a server just going
> away than a server that goes into pathological performance from using
> swap.

Agreed.

Ben.

> Desktops and laptops are obviously a different issue with different
> tradeoffs.
> 
-- 

Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Gabor Gombas]

On Thu, Jul 21, 2016 at 04:06:26PM +0300, Dmitry Bogatov wrote:

> For example, I, as happy owner of 8GB RAM, is perfectly fine with 3GB
> in /tmp, because I actually use less then 1Gb. On other hand, would I
> start 50 instances of Firefox, Gimp and other stuff, I would object
> putting 3GB in my /tmp, since it would make system swap.

I don't quite buy your argument. If you want to write 3GB to disk, then
you need to write 3GB to disk - it's the same amount of data, whether
you call it "filesystem" or "swap". But if you use a real filesystem to
store that data, then you will also have to deal metadata, which needs
to be protected from crashes so you want to flush caches from time to
time, which is expensive. tmpfs does not have such requirements, so it
should give you better performance. I guess someone should measure it...

Gabor

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Dmitry Bogatov]

[2016-07-21 21:22] Gabor Gombas 
>
> On Thu, Jul 21, 2016 at 04:06:26PM +0300, Dmitry Bogatov wrote:
>
> > For example, I, as happy owner of 8GB RAM, is perfectly fine with 3GB
> > in /tmp, because I actually use less then 1Gb. On other hand, would I
> > start 50 instances of Firefox, Gimp and other stuff, I would object
> > putting 3GB in my /tmp, since it would make system swap.
>
> I don't quite buy your argument. If you want to write 3GB to disk, then
> you need to write 3GB to disk - it's the same amount of data, whether
> you call it "filesystem" or "swap".

Let me explain. If I know that program need for it's operation
temporary 3GB of data, and I and only I can decide whether it is
apporiate to put it in tmpfs. As such, I find any attempt to guess on
the side of program vanity. Program must do it's job, not try to guess
my wishes.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Russ Allbery]

Ian Jackson  writes:

> Uhhh.  You run your systems with no swap at all ?

> That's your prerogative, of course.  But it's far from a default (or
> recommended) configuration.  I think that if you configure your system
> without swap, it is up to you do whatever else is necessary to make it
> work.  That might involve making /tmp not be on a tmpfs (if it is the
> default for some reason).

I never use swap on servers any more.  My experience is that swap is so
slow that if the system starts using swap, the services are all
essentially down anyway, and they're down in pretty much the worst case
scenario for clients (extremely slow and unreliable returns with no clean
"server is down" signal).  It's generally better for the system to panic
or start killing random processes than for it to go into swap.

This depends heavily on what type of server you have and what your
situation is, of course.  But swapless configurations are pretty common
these days in large-scale server farms that already have to tolerate any
one server going down.  It's a lot easier to tolerate a server just going
away than a server that goes into pathological performance from using
swap.

Desktops and laptops are obviously a different issue with different
tradeoffs.

-- 
Russ Allbery (r...@debian.org)   

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Simon McVittie]

On Thu, 21 Jul 2016 at 16:24:36 +0100, Ian Jackson wrote:
> I don't seem to be using tmpfs for /tmp by default.  My /tmp seems to
> be on /.  I wonder if that's just because I'm not using systemd, or
> whether it's because I did the partitioning by hand.

tl;dr: the Debian default is the same as you have, even under systemd.

Partitioning is only relevant if you allocate a /tmp partition and
configure it in fstab, in which case systemd (and hopefully all other
inits) will respect that.

Debian's systemd defaults to leaving /tmp part of the root filesystem,
but with a one-time migration to tmpfs /tmp if previously configured
by enabling tmp.mount or setting RAMTMP=yes. This is a Debian-specific
change, and could be reverted if there's ever consensus that it should be.

Upstream systemd uses tmpfs /tmp by default. This can be prevented
by masking tmp.mount, or reconfigured by mentioning /tmp (as
tmpfs, a disk partition or even a bind mount) in fstab, as part of the
general rule that /etc takes precedence over /[usr/]lib.

S

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Simon McVittie]

On Thu, 21 Jul 2016 at 20:41:38 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2016-07-21 at 13:38 +0100, Ian Jackson wrote:
> > Perhaps the right answer is instead that we should simply configure
> > more swap by default ?  (IIRC tmpfs data can be swapped.)
> 
> Yes. But that's not the default in our setups.

To be fair, neither is a tmpfs /tmp, and the Debian systemd maintainers
have gone to some length to keep /tmp on-disk by default (#783509).
If a sysadmin does one non-default thing, it seems reasonable to require
them to do another non-default thing to make it work optimally.

S

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

On Thu, 2016-07-21 at 21:22 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2016-07-21 at 15:42 +0200, Vincent Lefevre wrote:
> > On 2016-07-21 15:24:10 +0200, Philip Hands wrote:
> > > It's configurable.
> > > 
> > > See TMPFS_SIZE in /etc/defaults/tmpfs
> > 
> > If you mean /etc/default/tmpfs, it doesn't work with systemd
> > (as documented), and there's the global problem with swap.
> 
> And I was thinking of asking the same to the systemd maintainers. So thanks
> for
> mentioning this. Though I wish systemd honored values from these files.

So, as I understand it, systemd inherits the size value from, either /etc/fstab
or the kernel defaults (which is 50% of RAM).

And given that /tmp in Debian doesn't have a default listing in /etc/fstab, the
defaults would be picked up from the kernel defaults. Which would still be
capable of making many applications break, on a machine with lesser amount of
RAM.

BTW, is there an equivalent of, whats documented in /etc/default/tmpfs about:
TMPFS_SIZE=80%VM, in systemd ? I looked into tmpfs mount manpage section and it
does not talk about VM.

@Vincent: I agree with the pain about swap that Linux brings in. The assumption
everyones making is that faster block devices (SSDs mostly) will mitigate the
problem. And to a large extent it seems to have done that.
But I still have read [1] users report the bug existent, even on Android/Linux,
where I assume they are more commonly using Flash storage. 
Which confirms the arguments that slow rotational media is just part of the
problem (the bug provoker, as I like to put), the real problem lies in how I/O
scheduling works in Linux.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=12309#c639



-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

On Thu, 2016-07-21 at 15:42 +0200, Vincent Lefevre wrote:
> On 2016-07-21 15:24:10 +0200, Philip Hands wrote:
> > It's configurable.
> > 
> > See TMPFS_SIZE in /etc/defaults/tmpfs
> 
> If you mean /etc/default/tmpfs, it doesn't work with systemd
> (as documented), and there's the global problem with swap.

And I was thinking of asking the same to the systemd maintainers. So thanks for
mentioning this. Though I wish systemd honored values from these files.


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2016-07-21 at 15:24 +0200, Philip Hands wrote:
> It's configurable.
> 
> See TMPFS_SIZE in /etc/defaults/tmpfs
> 
> And it'll cheerfully use swap, so just make sure you have enough swap
> for your use case, and set the limit to suit your needs.
> 

Should this be the default ? Maybe I'll just file a bug report and see where it
goes.


> Alternatively, you can always create a new temporary location where you
> have enough space (i.e. ~/.tmp/ ) and then either set TMPDIR to that in
> the relevant user's shell profile/rc or define an alias such as:
> 
>   alias debdiff="TMPDIR=~/.debdiff-scratch-space debdiff"

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXkOk/AAoJEKY6WKPy4XVppfMQAKDiF84P7L211yEld58z/Mma
T8aCKoDSe6ZwbDU3Ex7y+n8rtjG0FMEVDNZUmKW/MBR9dPyyULnO2VOyitBq1n2/
wFcs4BFcyAxVquJbVFSFwGbM4LZwStd8kZlR5PoAcpTQtOA1R2b15p1ceuCYqDus
N47D9RkDWLK5ZJL5yu+4CpsMX5sYynLceLQv9WxfAdOE+3DIQ5HEsO7FeOL//TPx
WLIZIrAbfZQl0OQDpzRHvkIfefvqvVH09+GhrR5cUQWmepi7/dbNZDsIYEC5lazJ
vjKDGTs5UJDGjhcsSME4yLRABqzsA65spEe5jNUWMbIOU1BhFOS+3NCjvpGwyQ6W
x/AyErKhpWXO2Xlwp/ib9eiP5x72RkdZJE4/Pp5/ucS6nbEMAHYsJtNrGNTLaKgY
4LRmU6yUeITZlyfYlZWvf8rIt3JQ4VuQEmpKcxfeJrnq8L0Gn2ZJnS4/OxU/0Mxh
cf9wyDEK9uEaQJyO3qHEzx01fRSPtGAwMpyOKUqeN9QFCMZsQxz3aSVuB7jCmE16
iZ6YSIu89gElFlcOgEUkY5+bXiLoUd6v1Z2v8VUwdrPDDItrtX3nnx/P/nvympcO
fECqLFQyaVgX2lCVd8qRz2P0MKcJzU6+ZlroWzNf65kAvP940mHp1fUOKbFP4Fi8
nUdPfiGddXHk9Ri3xPIn
=u0Hb
-END PGP SIGNATURE-

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Ian Jackson]

Philip Hands writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR ?"):
> It's configurable.
> See TMPFS_SIZE in /etc/defaults/tmpfs

A sensible question to ask is whether the default is right.

I recently installed stretch on a new laptop with a large SSD and 16G
of RAM.  I set it up with 27G of swap (because I hate running out of
swap).  I have a bunch of per-user /run directories at 1.6G each.

I don't seem to be using tmpfs for /tmp by default.  My /tmp seems to
be on /.  I wonder if that's just because I'm not using systemd, or
whether it's because I did the partitioning by hand.

I'm tempted to change to RAMTMP=yes in /etc/default/tmpfs.  The
default size of that tmpfs (20%VM = 8.6G) would arguably be rather
small compared to the amount of underlying storage available.

> And it'll cheerfully use swap, so just make sure you have enough swap
> for your use case, and set the limit to suit your needs.

I wonder if the performance will be acceptable if one starts to use
tmpfs for large objects which require swapping.  On spinning rust the
default IO scheduler (cfq) is very poor for interactive workloads.


Vincent Lefevre writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR ?"):
> On 2016-07-21 18:19:43 +0530, Ritesh Raj Sarraf wrote:
> > Swap will come into effect when the kernel needs more memory.
> 
> Anyway, even if it had worked, swap should not be a solution for the
> limited /tmp size. The reason is that enabling swap can make the whole
> system freeze for several dozens of minutes when a program misbehaves.
> A misbehaving program should crash, not freeze the whole system.

Uhhh.  You run your systems with no swap at all ?

That's your prerogative, of course.  But it's far from a default (or
recommended) configuration.  I think that if you configure your system
without swap, it is up to you do whatever else is necessary to make it
work.  That might involve making /tmp not be on a tmpfs (if it is the
default for some reason).

Ian.

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Dmitry,

On Thu, 2016-07-21 at 16:06 +0300, Dmitry Bogatov wrote:
> 
> > > Should there be another TPMDIR? Like DTMPDIR, pointing to the
> > > underneath disk, where size is limited by the capacity available to
> > > partition/disk ?
> 
> Why? How would you define line between 'TMPDIR' and 'DTMPDIR'?
> 

I am exploring if we can/should have another one. I still haven't found any
environment variable to reference /var/tmp/

> For example, I, as happy owner of 8GB RAM, is perfectly fine with 3GB
> in /tmp, because I actually use less then 1Gb. On other hand, would I
> start 50 instances of Firefox, Gimp and other stuff, I would object
> putting 3GB in my /tmp, since it would make system swap.
> 

What about machines where RAM is much lesser ?

> In summary, only I, as user, can decide whether is fine to put several
> gigabytes in tmpfs, and it depends not only on RAM size. And I have such
> control by 'export TMPDIR=$HOME/.tmp'.
> 
> So regarding problem about debdelta, I think the right solution would
> be to put note in manpage, like 'debdelta need several gigabytes in
> TMPDIR for proper operation. Adjust TMPDIR accordingly.' and to *not*
> complicate programs.

I don't think this is a debdelta problem. If the defaults is to have TMPDIR as a
tmpfs, and if the defaults are to bind 50% of RAM for TMPDIR, then there can be
multiple apps breaking. It just depends on how much RAM your machine has.

I think a more sensible approach would be to allocate 50% of Virtual Memory for
TMPDIR, as the defaults.


- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXkOgvAAoJEKY6WKPy4XVpBwoP/0HA1rOwhdrzngR8S04DijSi
mFCiMhHuXF6DlK5eb9w7oloVoQ2yJ74puxi4f0jZLDYyvX5fY6rMUy02lL9btUuY
FZsHl4GfQawjPLuolMbcTsYiPbJbe0hyu+zuUx8Rs+SYefQPbkcVABhgK0aOIQcC
RZguye/6Iq1QW8uRD/0kPBCLM3k8av0Pp5X3OsF9tdpu0ZGxNrmBrt22aC8Wgpik
wML1IQwPbgNsO7Eq7Eh7hVBCyMu3JU2P2iOWWRKKk5jLt9TBvEZHIMGKhTJC0Bh3
A54eNeaOZEPjGQDanDH5eImI2NK8YNBAxy1F9TEXbHbesKzNHoAEbE8QXQEqpnGu
tCVrZ4QvQEbexrj3OxO9Ze2dTMIsASfhw9nqFBHEHHqaDE5i7MKU6/NmYFztVFJ+
6IyW92zeHEOQbNZjfP9wKiWGv3qrc6aNWyYG2orna8s5oYfrXTC/8OX+8C/3ZBZj
UOrxvSnjulDldpxiVPpdLZLuK9bf3VxuR49RDn2Zx2p2UugzF2hW71VO/yhqsUhM
E37rrUYEJazPuOwz4Fk85yhYFEBVltazGas19Mz5CZoDjt5l9AnXTWdYXpN6FnF5
dT0UBS3l5qCgM5P7x5zL66hB4GB+BwKlB/y5lzu4c+xrGIPZeEJdUVwSjoAg3LK4
I+u7zLHQjXVrqQYEV0WD
=6Qyg
-END PGP SIGNATURE-

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2016-07-21 at 13:38 +0100, Ian Jackson wrote:
> You are using `survives reboots' as a proxy for `on disk'; and using
> `on disk' as a proxy for `has enough space for large amounts of data'.

Yes. :-)

> I don't think this is a good approach.
> 
> It's true that /tmp has traditionally been smaller than /var/tmp,
> partly as an accident of partition and filesystem layout.
> 
> As a practical matter, there are big performance gains to be had from
> not requiring across-reboot (and, particularly, across-crash)
> persistence.
> 
> Perhaps the right answer is instead that we should simply configure
> more swap by default ?  (IIRC tmpfs data can be swapped.)

Yes. But that's not the default in our setups. Perhaps next step is to file a
wishlist bug report.


- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXkOYrAAoJEKY6WKPy4XVpaiEQAK+3+s4hV/GGvpsZrFo0ePii
PDQ6uFLEGEjfqgE3Y6Syw6gcrt/gmuC9DSVZ1kG0hXbPU9/9fhtQFZnM8tcu/Pfo
SVIODMxaZ9omDBYYl3XHjevM4nkJTPniRs2Mo6frsxE4n6bD1sjb+zMhIT4NFnzM
FzLXi8D4xyiTNhqcESrLz2+GyaOC6gEoHc8xZgaC4+REif66AlCoCzWwRuZzki0S
l5kMP5hjcZm0rTylqAHB1oAyw8Xd4snFYZm2U5qA+THSgI/mDQYCl4a8IlMj+5cn
qB+u43nGjYjeoDsXDkkVVNfBLsm/XFSE48D8OWDfqSZOsGZirJuLk7SYtcgdSXPO
0Iktf25ezLbnhzind1slONgy80Qge5kMDnOJYVT0Cssa4Yfr2ufuA/8pDignxY+L
eJnKqzGMHDnf/Q1I6gt6yj1wNa36gPMYe46EZFoCktQxW78Zpw0bUEtZYJ4xUQjd
Tq/n5ThTtEHV4x6ji8f3UoeSf8ycyBAVz3J5CXqKGoak6+kocCYIogVvILsOFuCf
V14FEuPnr69koT2eGW6R6R02dAU/wrKUcKhljTEabd0/g5Qx/IdhtkEzGLolvWRK
XhZ37jCuQNtKGlcKSwKdRsUjlGnfxHisoUgUhy57gL57DQeRcnH/3hOoQbybtXU9
siLMDcSuAGRqw1UNDD7W
=wbOb
-END PGP SIGNATURE-

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Vincent Lefevre]

On 2016-07-21 15:24:10 +0200, Philip Hands wrote:
> It's configurable.
> 
> See TMPFS_SIZE in /etc/defaults/tmpfs

If you mean /etc/default/tmpfs, it doesn't work with systemd
(as documented), and there's the global problem with swap.

> And it'll cheerfully use swap, so just make sure you have enough swap
> for your use case, and set the limit to suit your needs.
> 
> Alternatively, you can always create a new temporary location where you
> have enough space (i.e. ~/.tmp/ ) and then either set TMPDIR to that in
> the relevant user's shell profile/rc or define an alias such as:
> 
>   alias debdiff="TMPDIR=~/.debdiff-scratch-space debdiff" 

That's just a workaround. If some tool uses TMPDIR, it should work
in the first place.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Philip Hands]

Ritesh Raj Sarraf  writes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Thu, 2016-07-21 at 13:15 +0100, Neil Williams wrote:
>> > Now, back to the actual problem. For many applications, we rely on
>> > the TMPDIR environments. Tools like Python's modules help use these
>> > variables and not worry about the underneath platform.
>> > 
>> > Under Linux, with /tmp more commonly on tmpfs, how are developers
>> > dealing with it? tmpfs is limited and multi gigabyte operations may
>> > end up filling it all (as is the case in the debdelta bug report
>> > above).
>> 
>> As a drive backend, why doesn't swap work for this? There's no mention of 
>> swap
>> in the original bug report.
>
> Swap will come into effect when the kernel needs more memory.
>
> As I understand it, TMPDIR on tmpfs is capped, based on the amount of real RAM
> the machine has. And any application's view of TMPDIR is based on that capped
> size.

It's configurable.

See TMPFS_SIZE in /etc/defaults/tmpfs

And it'll cheerfully use swap, so just make sure you have enough swap
for your use case, and set the limit to suit your needs.

Alternatively, you can always create a new temporary location where you
have enough space (i.e. ~/.tmp/ ) and then either set TMPDIR to that in
the relevant user's shell profile/rc or define an alias such as:

  alias debdiff="TMPDIR=~/.debdiff-scratch-space debdiff" 

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Vincent Lefevre]

On 2016-07-21 18:19:43 +0530, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Thu, 2016-07-21 at 13:15 +0100, Neil Williams wrote:
> > > Now, back to the actual problem. For many applications, we rely on
> > > the TMPDIR environments. Tools like Python's modules help use these
> > > variables and not worry about the underneath platform.
> > > 
> > > Under Linux, with /tmp more commonly on tmpfs, how are developers
> > > dealing with it? tmpfs is limited and multi gigabyte operations may
> > > end up filling it all (as is the case in the debdelta bug report
> > > above).
> > 
> > As a drive backend, why doesn't swap work for this? There's no
> > mention of swap in the original bug report.
> 
> Swap will come into effect when the kernel needs more memory.

Anyway, even if it had worked, swap should not be a solution for the
limited /tmp size. The reason is that enabling swap can make the whole
system freeze for several dozens of minutes when a program misbehaves.
A misbehaving program should crash, not freeze the whole system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Dmitry Bogatov]

> > Should there be another TPMDIR? Like DTMPDIR, pointing to the
> > underneath disk, where size is limited by the capacity available to
> > partition/disk ?

Why? How would you define line between 'TMPDIR' and 'DTMPDIR'?

For example, I, as happy owner of 8GB RAM, is perfectly fine with 3GB
in /tmp, because I actually use less then 1Gb. On other hand, would I
start 50 instances of Firefox, Gimp and other stuff, I would object
putting 3GB in my /tmp, since it would make system swap.

In summary, only I, as user, can decide whether is fine to put several
gigabytes in tmpfs, and it depends not only on RAM size. And I have such
control by 'export TMPDIR=$HOME/.tmp'.

So regarding problem about debdelta, I think the right solution would
be to put note in manpage, like 'debdelta need several gigabytes in
TMPDIR for proper operation. Adjust TMPDIR accordingly.' and to *not*
complicate programs.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2016-07-21 at 13:15 +0100, Neil Williams wrote:
> > Now, back to the actual problem. For many applications, we rely on
> > the TMPDIR environments. Tools like Python's modules help use these
> > variables and not worry about the underneath platform.
> > 
> > Under Linux, with /tmp more commonly on tmpfs, how are developers
> > dealing with it? tmpfs is limited and multi gigabyte operations may
> > end up filling it all (as is the case in the debdelta bug report
> > above).
> 
> As a drive backend, why doesn't swap work for this? There's no mention of swap
> in the original bug report.

Swap will come into effect when the kernel needs more memory.

As I understand it, TMPDIR on tmpfs is capped, based on the amount of real RAM
the machine has. And any application's view of TMPDIR is based on that capped
size.

- From the tmpfs(5) manpage, which seems to be Debian specific, it mentions that
50% of RAM will be used, by default.

On the machine where the (debdelta) bug is seen, I have enough RAM.

rrs@chutzpah:~/Community/Packaging$ free -m
  totalusedfree  shared  buff/cache   available
Mem:   738714034727  3712565677
Swap:  8579   08579


And the documented defaults for tmpfs reflect below.

rrs@chutzpah:~/Community/Packaging$ df -h /tmp/
Filesystem  Size  Used Avail Use% Mounted on
tmpfs   3.7G 0  3.7G   0% /tmp


- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXkMTnAAoJEKY6WKPy4XVpkd0P/35T8/2Gct3cJieKrQtZY+ac
Uw4sAhv/OeUHAQ1A19SHClIZvRwCznhwEayg8+AfjRkYJjyhsAH/j9OTALWN18z1
SUzxlOpWiQd/oIu6k7scd6xLsKd/9TbuVoeWfrNu9mSciNacS7kK4oaQKGLF5+Jg
+3DG3L/lwrDDzO/kvhlQwnNkVoJGNOTz8ss5MydxS5dIjagz+vMqQFgel9vBPrfE
hVjcWZZFUPXTXPuwjNGRX/NthDfbHq6Ix9fbBTSHzNKt4aftKBRfGVc5c2y/WWKl
S3bW2zui+yo42g+5Qe+eKIxc+KMDs/IAEgLhe7F044WC7h3CP1M0sGEO5Rk7lzje
/AX8qeH3A5sS+54PS1v3hv+Q4AZna3/S5GkoFS9D7iYWPrkAzQdVPoVUYlbJn07t
nTdBnVdwwh5Y0lNCreRkQ7WVmLHnz5BA+370kgKM3hRVZotzxba/DGD+ODU8s7Iy
aL/UtWoWXo2orrVWJAtI7Lp8TV0iINmCMM9DUckF8b5+CtUEuqkQJ1zr5kR6J1WM
TG3b15NIiKmBwVKLNyASXQ61am7/vfz1O9V57MVdjkqjLhe9RL/jSBcCswmZ6cZ1
KeYwvEfrW+kvBCie9utkdfvIqfYzOd+qgcfPmh8JEaxSSV7yHe77LyfeoVvkvokC
LU/Pz2EaILrGGU33LOnt
=7EXe
-END PGP SIGNATURE-

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ian Jackson]

Ritesh Raj Sarraf writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR 
?"):
> Some more search pointed the following link that talks about /var/tmp
...
> So this could be the answer to DTMPDIR (Disk TMPDIR).

You are using `survives reboots' as a proxy for `on disk'; and using
`on disk' as a proxy for `has enough space for large amounts of data'.
I don't think this is a good approach.

It's true that /tmp has traditionally been smaller than /var/tmp,
partly as an accident of partition and filesystem layout.

As a practical matter, there are big performance gains to be had from
not requiring across-reboot (and, particularly, across-crash)
persistence.

Perhaps the right answer is instead that we should simply configure
more swap by default ?  (IIRC tmpfs data can be swapped.)

Ian.

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Neil Williams]

On Thu, 21 Jul 2016 17:19:27 +0530
Ritesh Raj Sarraf  wrote:

> Hi,
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831998
> 
> This bug is an example of the problem. I am bringing it here to know
> views of fellow developers.
> 
> 
> I am not sure if there's an fd.o defined standard for environment
> variables, but a quick web search pointed to the IEEE and Open Group
> link.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
> 
> None of the standards talk about where TMPDIR should be pointing to.
> On GNU/Linux, I recollect it pointing to /tmp and always wondered
> what environment variable would point to /var/tmp
> 
> On the Debian front, I can't recollect what our official stand is. I
> could find a conversation at the following link. It is fairly recent
> from 2012. https://lists.debian.org/debian-devel/2012/06/msg00311.html
> 
> My /tmp is on tmpfs. I just don't recollect if it was the default or
> I enabled it explicitly. Currently, it is managed by systemd, but I
> do recollect initscripts providing similar feature.
> 
> ● tmp.mount - Temporary Directory
>    Loaded: loaded (/usr/share/systemd/tmp.mount; enabled; vendor
> preset: enabled)
>    Active: active (mounted) since Wed 2016-07-20 21:50:05 IST; 19h ago
> Where: /tmp
>  What: tmpfs
>  Docs: man:hier(7)
>    http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
>    CGroup: /system.slice/tmp.mount
> 
> Jul 20 21:50:05 learner systemd[1]: tmp.mount: Directory /tmp to
> mount over is not empty, mount
> Jul 20 21:50:05 learner systemd[1]: Mounting Temporary Directory...
> Jul 20 21:50:05 learner systemd[1]: Mounted Temporary Directory.
> 
> 
> 
> Now, back to the actual problem. For many applications, we rely on
> the TMPDIR environments. Tools like Python's modules help use these
> variables and not worry about the underneath platform.
> 
> Under Linux, with /tmp more commonly on tmpfs, how are developers
> dealing with it? tmpfs is limited and multi gigabyte operations may
> end up filling it all (as is the case in the debdelta bug report
> above).

As a drive backend, why doesn't swap work for this? There's no mention of swap 
in the original bug report.

> The whole idea of tmpfs for /tmp was performance. Email attachments
> could be temporarily opened under tmpfs
> 
> 
> But what do we do about larger operations where temporary data may
> have the possibility of being huge. I think most video/audio
> transcoding workflows may be hit by this.
> 
> Should there be another TPMDIR? Like DTMPDIR, pointing to the
> underneath disk, where size is limited by the capacity available to
> partition/disk ?
> 
> This could allow developers to choose one over the other based on
> their needs. It could also help standardize it as a fallback.
> 
> -- 
> Given the large number of mailing lists I follow, I request you to CC
> me in replies for quicker response


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpnv8xVMxVQ2.pgp
Description: OpenPGP digital signature

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

On Thu, 2016-07-21 at 17:19 +0530, Ritesh Raj Sarraf wrote:
> 
> I am not sure if there's an fd.o defined standard for environment variables,
> but
> a quick web search pointed to the IEEE and Open Group link.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
> 
> None of the standards talk about where TMPDIR should be pointing to. On
> GNU/Linux, I recollect it pointing to /tmp and always wondered what
> environment
> variable would point to /var/tmp

Some more search pointed the following link that talks about /var/tmp

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

To quote:

*
/var/tmp : Temporary files preserved between system reboots

Purpose

The /var/tmp directory is made available for programs that require temporary
files or directories that are preserved between system reboots. Therefore, data
stored in /var/tmp is more persistent than data in /tmp.

Files and directories located in /var/tmp must not be deleted when the system is
booted. Although data stored in /var/tmp is typically deleted in a 
site-specific 
manner, it is recommended that deletions occur at a less frequent interval than
/tmp.
*

So this could be the answer to DTMPDIR (Disk TMPDIR).
The only missing bit is the Environment Variable. Does anyone know of a standard
way to referencing this ?


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part

TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

Hi,

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831998

This bug is an example of the problem. I am bringing it here to know views of
fellow developers.


I am not sure if there's an fd.o defined standard for environment variables, but
a quick web search pointed to the IEEE and Open Group link.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

None of the standards talk about where TMPDIR should be pointing to. On
GNU/Linux, I recollect it pointing to /tmp and always wondered what environment
variable would point to /var/tmp

On the Debian front, I can't recollect what our official stand is. I could find
a conversation at the following link. It is fairly recent from 2012.
https://lists.debian.org/debian-devel/2012/06/msg00311.html

My /tmp is on tmpfs. I just don't recollect if it was the default or I enabled
it explicitly. Currently, it is managed by systemd, but I do recollect
initscripts providing similar feature.

● tmp.mount - Temporary Directory
   Loaded: loaded (/usr/share/systemd/tmp.mount; enabled; vendor preset:
enabled)
   Active: active (mounted) since Wed 2016-07-20 21:50:05 IST; 19h ago
Where: /tmp
 What: tmpfs
 Docs: man:hier(7)
   http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
   CGroup: /system.slice/tmp.mount

Jul 20 21:50:05 learner systemd[1]: tmp.mount: Directory /tmp to mount over is
not empty, mount
Jul 20 21:50:05 learner systemd[1]: Mounting Temporary Directory...
Jul 20 21:50:05 learner systemd[1]: Mounted Temporary Directory.



Now, back to the actual problem. For many applications, we rely on the TMPDIR
environments. Tools like Python's modules help use these variables and not worry
about the underneath platform.

Under Linux, with /tmp more commonly on tmpfs, how are developers dealing with
it? tmpfs is limited and multi gigabyte operations may end up filling it all (as
is the case in the debdelta bug report above).

The whole idea of tmpfs for /tmp was performance. Email attachments could be
temporarily opened under tmpfs


But what do we do about larger operations where temporary data may have the
possibility of being huge. I think most video/audio transcoding workflows may be
hit by this.

Should there be another TPMDIR? Like DTMPDIR, pointing to the underneath disk,
where size is limited by the capacity available to partition/disk ?

This could allow developers to choose one over the other based on their needs.
It could also help standardize it as a fallback.

-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part