Re: how to increase space for tmpfs /tmp
On 20120329_095413, Andrei POPESCU wrote:
> On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote:
> > >
> > > You could have also considered uncompressing the tarball somewhere else,
> > > like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially
> > ^^^^^^^^^ ^^^^^^^^^
> > On my computer that is running wheezy neither of these suggestions work,
> > because, I think, these are not mount points supporting access to external
> > physical disk hardware.
> You must be misunderstanding me, I meant "some directory in your home",
> because on most systems /home has enough space.
> > I tested this suggestion this morning. I don't
> > fully understand this, but I have been told that access to the original
> > /tmp file requires an entry in /etc/fstab.
> Err... your original /tmp is a directory on / not a file and if you
> don't mount anything there your system will happily use the available
> space on / (the root partition).
>  unless you had a dedicated partition, but AFAIK in such a case you
> wouldn't get a tmpfs anyway
> > Think about it. Who is supplying this extra hardware? Any specialized
> > software that requires scratch files because the work is too large to
> > fit in ram is dead in the water with this change, and changing the
> > setting of RAMTMP does not fix the problem, or any of the work-arounds
> > that have been suggested so far. I think this is a serious flaw in the
> > current wheezy, a release critical flaw perhaps. My particular problem
> > is a project in which I regularly need to sort files 2 to 3 GB in size
> > on a computer with less than 1 GB of ram and 370 GB of rotating disk.
> > But I am sure there are other problems needing real, physical scratch
> > space running very nicely on computers old enough to have once run
> > woody. And now they are to be broken by something in wheezy software?
> > Can this happen? Really?
> Why do you think such scratch space should be in /tmp (regardless of
> whether /tmp is on tmpfs, a separate partition or just a directory on
Why? Because the last time I looked which was long ago, using /tmp for
scratch space was recommended practice in the FHS. I didn't decide to
use /tmp when I started using it. /tmp was used by Debian packages and
I used the packages. Then I read the FHS to try to understand how they
managed to just do something that I well knew required scratch space.
And there it was. Maybe not a requirement, but an indication that this
was a useful result of coding to the standard. I question whether any
debian package manager has ever released a package to testing without
first doing some tests to be sure it used /tmp in a reasonable
fashion. Whenever a software item arrived for packaging, my
understanding is, that the bulk of the work of packaging is bringing
it into compliance with FHS. As a consequence, I have very little
patience with the argument that developers would sudden lose all self
control and good sense merely because they have this new feature called
tmpfs or ramfs. There is no record of them having been, as a group, so
Also, today I am having an experience which seems to indicate that
approx, the debian repository cacher, also has used /tmp for scratch
files. In fact, after several hours of poking at it, I have abandoned
use of approx for the while until this whole thing is sorted out by
people who actually understand how Debian works, which is a small
group of experts to which I surely don't deserve to belong.
Paul E Condon