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.
No. You misunderstand me. There is a new extra requirement on TMPDIR, a
restriction on ones choise of its value. A directory entry on a disk
file system is not enough. It must be a directory entry that has a line
in /etc/fstab that enables its use as a mount point to real separate
partition. At least that is the way it is now. If this restriction were
removed by some change in the implementation that I know not how to do...
then your suggestion would likely work and the old way of using /tmp
would also work.
> > 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.
In UNIX all directories are files ... special files that serve a
special system defined function, but files in the sense that they are
not inodes, or sectors, or blocks, etc. Linux follows UNIX on this
innovation of long ago.
> Err... your original /tmp is a directory on / not a file[1] and if you
> don't mount anything there your system will happily use the available
> space on / (the root partition).
>
> [1] unless you had a dedicated partition, but AFAIK in such a case you
> wouldn't get a tmpfs anyway
I don't know why I get a tmpfs. I didn't ask for it. I have supposed
it came with a new way of doing file handling in the system software,
part of a new implementation that was supposed to be a work-alike
replacement of the previous version.
I never had a dedicated partion for /tmp and now it is required. That,
to me, is a change. I fixed it when I learned that it is now required,
and I think it would be nice to go back to the old way because the old
way did not require a separate partition. But I repeat myself. Enough.
What happens will happen.
>
> > 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
> /)?
>
> Kind regards,
> Andrei
> P.S. I accidentally did some re-wrapping, how long do you set your
> lines?
The default in mutt, whatever that is. I like defaults. That is the
main thing that originally attracted me to Debian. It offered defaults
that worked.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: