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

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



-----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
              total        used        free      shared  buff/cache   available
Mem:           7387        1403        4727          37        1256        5677
Swap:          8579           0        8579


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-----


Reply to: