Re: how to increase space for tmpfs /tmp
On 20120329_011019, Andrei POPESCU wrote:
> On Mi, 28 mar 12, 20:47:45, Camaleón wrote:
> > On Wed, 28 Mar 2012 21:55:01 +0300, Andrei POPESCU wrote:
> >
> > > On Mi, 28 mar 12, 17:02:23, Camaleón wrote:
> >
> > (...)
> >
> > >> > but the short version would be "You can't make an omelette without
> > >> > breaking eggs"
> > >>
> > >> Which explains little about your arguments (that's a general stanza)
> > >> >:-)
> > >
> > > Well, so is yours, unless we are talking past each other. I was
> > > specifically addressing only that paragraph, out of context.
> >
> > I didn't know you were interested in my arguments... they can be read
> > here:
> >
> > http://lists.debian.org/debian-user/2011/11/msg02155.html
> > http://lists.debian.org/debian-user/2011/11/msg02207.html
> > http://lists.debian.org/debian-user/2012/03/msg00280.html
>
> We are still talking past each other on this one. Let me try again[1]: I
> was only disagreeing with you on the rather general statement that
> defaults should not change when they create problems for users. Nothing
> more.
>
> [1] but I won't be posting anymore on this, it's OT already
>
> > > It seems to me you are expecting specific arguments about the /tmp on
> > > tmpfs issue. As far as I recall you did read through the debian-devel
> > > discussion(s), what point is there for me to repeat it here (even if my
> > > memory is faulty and you did not read it)?
> >
> > I read the thread it was mentioned when I first asked for feedback, which
> > was this:
> >
> > http://lists.debian.org/debian-devel/2011/11/threads.html#00281
> >
> > But to be sincere, I don't remember "all" of the contents of the posts
> > nor "who" posted there "what"... and now you tell, I can't see any post
> > belonging to you in that thread. Maybe you made your comments afterwards?
>
> I most probably didn't contribute at all. What for? People more
> knowledgeable than me and with more real life experience were already
> debating the issue with interesting arguments for both "sides".
>
> > > You expected to be able to uncompress an archive of unspecified size to
> > > /tmp on a testing system.
> >
> > "Unspecified size"?
>
> If you did mention a size I must have missed it, sorry for that.
>
> > It was just the kernel source (75 MiB). Wow. How. Big. >:-)
>
> Since this created problems for you I'm assuming either a small amount
> of RAM (less than 512 MB?[2]) which points to a lower spec machine that
> would need special care anyway, or that something else was already
> hogging /tmp (which kinda' proves Roger's point).
>
> [2] 20% of 512 MB is still aprox. 100MB. My laptop is up 2 days and I'am
> running iceweasel, xxxterm, libreoffice, aptitude, mutt, pidgin, but
> /tmp usage is still below 1MB (844 KB according to 'df -h').
>
> > > 1. you may have had similar issues uncompressing that on any other
> > > filesystem (small partition, quota, etc.)
> >
> > I doubt it becasue I tend to put special care for that can't happen (my netbook
> > has a 250 GiB. hard disk with only 2 partitions: /swap (2 GiB) and "/" (the
> > remaining space). Since I returned "/tmp" to the root filesystem I've had no
> > more "hiccups".
>
> 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. 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. 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?
I hope some work-around that actually survives testing is suggested soon.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: